From ipp-archive Fri Jan 2 09:34:58 1998 Return-Path: ipp-owner 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 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: 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-archive Fri Jan 2 09:34:58 1998 Return-Path: ipp-owner 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 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : 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 ipp-archive Fri Jan 2 13:05:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 2 13:30:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 2 16:45:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Jan 3 00:00:06 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA11668 for ipp-outgoing; Fri, 2 Jan 1998 23:56:58 -0500 (EST) From: q219TG15L@1blowup.net DATE: 01 Jan 98 11:59:58 PM Message-ID: TO: eduacation@children423.net Subject: IPP> Give Your Child "One of the Best Children's Videos"" Sender: ipp-owner@pwg.org Precedence: bulk The holidays are upon us. If you're like a lot of people, you struggle to find gifts for your children that will entertain and amuse them at the same time. Well, here's a gift that will delight your child - A Is For Airplane! "A Is For Airplane" is the award-winning educational video that shows kids all the fun and teamwork involved in running an airline. "A Is For Airplane" gets viewers behind the scenes at the airport! Kids get to see: * The ticket counter! * Inside the baggage system! * On the ramp with the baggage loaders and fuelers! * In the catering kitchens! * Inside the control tower! * In the hangar with the mechanics! * At the boarding gate! * And even in the COCKPIT of a real Boeing 757! Parenting Magazine calls "A Is For Airplane" "One of the Best Videos of 1996!" It's also Approved by the Parent's Choice Foundation! Thousands of copies of "A Is For Airplane" have been sold for $14.95, but as an Internet Special this holiday season you can get "A Is For Airplane" for only $11.95 (plus shipping and handling.) ORDER TODAY FOR GUARANTEED HOLIDAY DELIVERY! You can order "A Is For Airplane" by calling our toll-free number - 800-250-4210. If you'd like more information, visit our Website at www.ppmm.com/jfp/jfp1297.htm or CLICK HERE! Thank you for your time... Johnson Family Productions Madison, WI From ipp-archive Sat Jan 3 11:00:12 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Mon Jan 5 10:45:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 11:22:41 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Carl-Uno wrote: >Don, > >It turmns out that there are two kinds of things that people would lik= e to >discuss in the January IPP meeting: > >1) Start discussion about various extensions that were left out from I= PP 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 alrea= dy >scheduled Wednesday slot, but would like to find out quickly if we cou= ld get >a room for the testing issue discussions on Thursday. I assume that th= e >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 travelin= g plans. My interests would overlap. I'd prefer to adjust agendas to fit all top= ics inline. Harry Lewis - IBM Printing Systems = From ipp-archive Mon Jan 5 11:55:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 12:30:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Mon Jan 5 12:49:11 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 13:00:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 14:15:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 15:35:41 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 16:25:42 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 18:00:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 19:05:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 19:39:17 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 19:40:50 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 20:20:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 21:25:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 5 21:30:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 08:20:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 08:25:51 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I wonder how fruitful it will be to devote an entire day to Testing, gi= ven the low participation thus far in these discussions. There has not even been an= y 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-archive Tue Jan 6 14:35:55 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 preferab= ly, 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 telne= t > client than it took me to write and debug clients/servers for textual= > protocols. I had to build a complex debugging service into the clien= t > which I've never needed in textual protocols. I will note that telne= t > 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-archive Tue Jan 6 15:20:55 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 16:09:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 16:34:52 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 17:20:57 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 19:15:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Tue Jan 6 20:46:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 21:06:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 21:06:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 21:16:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 22:46:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 6 23:21:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 02:06:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 08:51:09 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Wed Jan 7 09:01:10 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Well, I've finally made it through all of me email after being on vacat= ion 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 clear= ly 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-archive Wed Jan 7 09:56:10 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Wed Jan 7 10:41:11 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 11:21:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 11:46:12 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 12:16:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 12:46:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 15:46:14 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 15:46:14 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 16:11:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 16:17:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 16:17:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 16:53:42 1998 Return-Path: ipp-owner 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" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by norman.cp10.es.xerox.com id LAA03025 Sender: ipp-owner@pwg.org Precedence: bulk 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= =20 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=20 the handling of unknown or unsupported operation attributes. I suggest t= hat=20 the dashed line be deleted and the two last paragraphs be indented at the= =20 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=20 length is not legal for that attribute syntax, REJECT/RETURN=20 'client-error-bad-request'. ELSE copy the attribute and value to the Unsupported Attributes respon= se=20 group and change the attribute value to the out-of-band 'unsupporte= d'=20 value, but otherwise ignore the attribute. Note: Future Operation attributes may be added to the protocol=20 specification that may occur anywhere in the specified group. When= the=20 operation is otherwise successful, the IPP object returns the=20 'successful-ok-ignored-or-substituted-attributes' status code. =20 Ignoring unsupported Operation attributes in all operations is analogous=20 to the handling of unsupported Job Template attributes in the creat= e and Validate-Job operations when the client supplies the=20 "ipp-attribute-fidelity" Operation attribute with the 'false' value= .=20 ----------------------------------------------- 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 majo= r 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. =20 For example, if an IPP object doesn=92t support the OPTIONAL "job-k-octet= s" attribute (because of the implementation or because of some administrator= =92s 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-archive Wed Jan 7 16:53:46 1998 Return-Path: ipp-owner 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" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by norman.cp10.es.xerox.com id LAA03076 Sender: ipp-owner@pwg.org Precedence: bulk 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=20 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 amo= ng 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 thos= e supported or is not in the range supported, then the IPP object REJECTS t= he 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. =20 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) a= re supported or in the range supported, i.e., the value of the "xxx" attribu= te 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 o= f 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 Unsupporte= d 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=92t recognize/support a Job Template attribute, i.e., th= ere is no corresponding Printer object "xxx-supported" attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see t= he 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=92t support the OPTIONAL "job-k-octet= s" attribute (because of the implementation or because of some administrator= =92s 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=92s choic= e 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-supporte= d" Printer attribute that is not configured, the validation fails, but the request is accepted or rejected depending on whether the value of=20 "ipp-attribute-fidelity" is 'false' or 'true, respectively. Not configuring "xxx-supported" doesn't change how "ipp-attribute-fidelity" w= orks. NOTE: Clients MUST NOT supply the out-of-band value of 'no-value' as spec= ified in section 4.1, else the validation check with an configured "xxx-support= ed" value would succeed. From ipp-archive Wed Jan 7 16:57:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 16:57:46 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 17:03:07 1998 Return-Path: ipp-owner 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@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 Precedence: bulk --=====================_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-archive Wed Jan 7 17:41:45 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Wed Jan 7 18:57:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 19:12:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 19:12:36 1998 Return-Path: ipp-owner 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 Precedence: bulk --=====================_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-archive Wed Jan 7 20:02:33 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 20:12:23 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 20:17:14 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 7 22:47:10 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 00:42:12 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 09:52:17 1998 Return-Path: ipp-owner 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 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: 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 ipp-archive Thu Jan 8 11:07:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 13:42:20 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Thu Jan 8 15:32:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 15:57:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 16:07:21 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@Pwg.Org Precedence: bulk > 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 "overrid= e 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 @ int= ernet Subject: IPP> Re: URI scheme and port numbers for TLS > Is it assumed that each application that uses TLS uses its own origin= al > scheme e.g. "http" or should it allocate a new scheme if combined wit= h 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 fo= r IPP > (differently from HTTP) when using HTTP as transport? If you think ne= w > schemes and ports are needed, do we need one for use of IPP without T= LS, > 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-archive Thu Jan 8 16:32:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 16:37:27 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Thu Jan 8 20:27:23 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 21:32:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 21:42:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 21:57:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 8 22:12:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 10:32:30 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 s= tream instructions, I'm confused by 4.2.10 orientation-requested (type2 enum)= which, by its definition, indicates the opposite (this attribute WILL be overr= idden 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 wi= th 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 wrot= e 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 explici= tly specify the orientation (e.g. PostScript), this attribute has no meanin= g -- it neither alters the orientation nor specifies the existing orientatio= n. ----------------------------------------------- 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 i= s > specified within the document format generated by the device driver a= t > print time. However, some document formats (such as 'text/plain') do = not > support the notion of page orientation, and it is possible to bind th= e > orientation after the document content has been generated. This attr= ibute > provides an end user with the means to specify orientation for such > documents when the IPP Printer performs the formatting. > = From ipp-archive Fri Jan 9 10:47:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 11:37:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 13:22:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 15:57:34 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 fo= rmat. I know this is revisiting an old issue but we need to make sure we do t= he right thing. When the current format was proposed there was no good met= hod 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 XM= L (and protocol specific HTTP commands). By ensuring that we are in the c= entre of these standards we will be able to leverage many common tools that w= ill emerge to support and manage these protocols. There will definitely be down-sides so we need to debate this issue - n= ot least the investment that some of us have already made in building usin= g the current spec. I think that somebody from MS will be in Hawaii. Paul Moore = From ipp-archive Fri Jan 9 16:07:34 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 17:07:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 17:27:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 17:52:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 17:57:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 18:07:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 18:07:37 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 18:12:36 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 18:27:38 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 >P= DL. 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... inte= nded 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 doe= s 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 probab= ly 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/9= 8 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 contai= ns. 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 w= ith >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 wro= te >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 explic= itly >specify the orientation (e.g. PostScript), this attribute has no meani= ng -- >it neither alters the orientation nor specifies the existing orientati= on. >----------------------------------------------- >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 t= he >> orientation after the document content has been generated. This att= ribute >> provides an end user with the means to specify orientation for such >> documents when the IPP Printer performs the formatting. >> > > > > > > > > > = From ipp-archive Fri Jan 9 18:37:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 18:47:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 19:12:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 19:28:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 20:53:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 21:54:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 22:09:10 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 23:34:46 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 9 23:39:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Jan 10 12:54:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Jan 10 13:54:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Jan 10 18:54:36 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 08:34:57 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Mon Jan 12 09:19:57 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Mon Jan 12 11:14:58 1998 Return-Path: ipp-owner 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 Precedence: bulk ______________________________ 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-archive Mon Jan 12 11:14:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 12:24:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 12:59:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 13:15:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 15:05:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 16:20:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 16:53:28 1998 Return-Path: ipp-owner 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 Precedence: bulk You may find this XML web page very useful for XML beginners. http://www.sil.org/sgml/xml.html Chen From ipp-archive Mon Jan 12 16:55:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 17:55:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 12 21:20:07 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 13 12:05:16 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > I found it rather easy to implement when I did it. Perhaps you had an implementation in mind when you wrote the spec. Eas= e 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 go= od point, too. What I meant is that it's redundant to specify a unique co= mpound attribute syntax for these two specific attributes (nameWithLanguage an= d 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-archive Tue Jan 13 12:10:16 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Tue Jan 13 12:10:17 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Tue Jan 13 12:20:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 13 12:35:20 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 13 15:20:26 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk >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-archive Tue Jan 13 19:20:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 13 20:10:30 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 09:50:37 1998 Return-Path: ipp-owner 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 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: 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-archive Wed Jan 14 13:10:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 14:00:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 14:05:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 15:05:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 15:10:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 15:30:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 15:50:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 18:55:43 1998 Return-Path: ipp-owner 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 Precedence: bulk >>> 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-archive Wed Jan 14 19:35:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 14 20:30:50 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 15 15:06:02 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 t= race 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 th= e trace repository.) This is one of the techniques we plan to use for interoperability testi= ng. Here is some example Java 1.1 code for a simple driver: // Server which listens on port 80 and transmits a file called "respons= e" // 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 fil= e { Socket readsock; reader(Socket sock) { readsock =3D sock; } public void run() { try { byte b[] =3D new byte[32768]; int len =3D 0; InputStream in =3D readsock.getInputStream(); FileOutputStream fout =3D new FileOutputStream("request"); while ((len =3D in.read(b)) > 0) fout.write(b, 0, len); } catch (Exception e) { e.printStackTrace(); } } } class writer implements Runnable // Reads from file, writes to socke= t { Socket writesock; writer(Socket sock) { writesock =3D sock; } public void run() { try { byte b[] =3D new byte[32768]; int len =3D 0; OutputStream out =3D writesock.getOutputStream(); FileInputStream fin =3D new FileInputStream("response"); while ((len =3D fin.read(b)) > 0) out.write(b, 0, len); System.err.println("Sent response."); } catch (Exception e) { e.printStackTrace(); } } } driver() throws IOException { ServerSocket listener =3D new ServerSocket(80); Socket serverSock =3D listener.accept(); System.err.println("Accepted connection."); Thread t1 =3D new Thread(new reader(serverSock)); Thread t2 =3D 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 fo= r. Unfortunately the client does not do anything unless it is interacting with an IPP Server. Steve = From ipp-archive Thu Jan 15 16:01:03 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA25220 for ipp-outgoing; Thu, 15 Jan 1998 15:57:45 -0500 (EST) From: 8dmBBpwUT@a1oI.com DATE: 14 Jan 98 3:36:30 PM Message-ID: TO: tell@alltheworld35.com Subject: IPP> Let Us Do It For You! Sender: ipp-owner@pwg.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ..$350 PER MILLION ADDRESSES SENT ..$250 PER 1/2 MILLION ADDRESSES SENT THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by six of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 60-80,000 addresses extracted daily. They are fresh! Over 40 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. $50 per page/25 lines per page beyond 2 pages. We do not do targeted mailings at this price. Targeted mailings: $150 per 50,000 addresses extracted or less. We can extract by country, occupation, organizations, associations, product, etc. If we can not search and extract what you need, then nobody can. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 6 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. From ipp-archive Thu Jan 15 17:06:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 15 21:56:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Fri Jan 16 14:06:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 16 14:16:16 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Fri Jan 16 15:21:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 16 16:11:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 16 18:51:19 1998 Return-Path: ipp-owner 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 Precedence: bulk --=====================_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-archive Sat Jan 17 11:41:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 19 09:46:58 1998 Return-Path: ipp-owner 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 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: 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-archive Mon Jan 19 10:07:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 19 11:57:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 19 12:47:01 1998 Return-Path: ipp-owner 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 Precedence: bulk [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-archive Mon Jan 19 12:52:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 19 19:12:05 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk The weakness with the MIME way is that it's either unsafe or slow -- ei= ther you arbitrarily pick a boundary string and hope that it doesn't appear in t= he binary data, or you prescan the data to make sure. Content-length avoi= ds 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@pw= g.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-archive Mon Jan 19 20:57:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 20 05:42:11 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Tue Jan 20 06:57:12 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Tue Jan 20 12:12:15 1998 Return-Path: ipp-owner 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 Precedence: bulk >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-archive Tue Jan 20 12:32:16 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 characte= rs. 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 - 7= 0 - 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) / (25= 6 ** 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 small= er 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 appea= r in the > binary data, or you prescan the data to make sure. Content-length avoi= ds 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 statisticall= y unlikely to ever appear in the message text that the chances of, say me= ssage corruption as a result of undetected network errors are many orders of magnitude greater. Ned = From ipp-archive Tue Jan 20 15:22:16 1998 Return-Path: ipp-owner 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 Precedence: bulk > > 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-archive Tue Jan 20 20:07:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 20 20:42:19 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 21 12:12:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 21 14:17:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Thu Jan 22 01:37:41 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 22 17:02:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 22 18:22:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 23 12:32:54 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 23 12:47:56 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 23 15:42:56 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 23 20:28:01 1998 Return-Path: ipp-owner 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 Precedence: bulk OK to send an e-mail to ipp@pwg.org? From ipp-archive Fri Jan 23 23:03:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 23 23:18:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 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 Precedence: bulk I just read through your XML example and I wonder why you don't use the "encoding" XML attribute in the " 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 Precedence: bulk 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-archive Sat Jan 24 02:38:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Jan 24 17:03:13 1998 Return-Path: ipp-owner 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 Precedence: bulk Hi Bob, I agree that the initial ' 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 Precedence: bulk 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-archive Mon Jan 26 17:53:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Jan 26 20:18:52 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Jan 27 01:38:55 1998 Return-Path: ipp-owner 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-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk >>> 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-oriente= d >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. =20 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=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 ************************************************************ From ipp-archive Tue Jan 27 15:19:04 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 wi= th 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 HTT= P, 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. Usi= ng 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 We= b, 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-orie= nted programming. Or you can view a web server as a collection of agents (computational entities), of which some serve documents, whil= e others perform activities like "copy" or "server diff." In fact, there= may be many agents capable of performing an activity, and a single agent ma= y be capable of handling more than one type of activity. On the OO view of H= TTP, an HTTP message is directed to an object (the Request-URI), which handles the method in the request message. On the a= gent view of HTTP, an HTTP message is directed to an agent (or a default HTT= P agent), which then handles either the HTTP/1.1 style message or process= es 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 is= n'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 metho= ds: 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 t= han 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 t= he same thing. 11. The existing Web framework is built around methods. If we are talk= ing 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? Wo= uld <> 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-archive Wed Jan 28 08:29:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 28 09:04:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 28 09:29:14 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 28 10:24:14 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 p= oint 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 desk= top. 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-archive Wed Jan 28 11:19:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 28 12:49:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 28 23:09:23 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Jan 28 23:09:24 1998 Return-Path: ipp-owner 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 Precedence: bulk > -----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-archive Thu Jan 29 05:29:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 29 08:49:30 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk >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-archive Thu Jan 29 21:44:37 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Jan 29 23:29:39 1998 Return-Path: ipp-owner 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 Precedence: bulk >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-archive Fri Jan 30 02:49:41 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk As requested, I reafirm my decision, as expressed at the meeting in Mau= i, to send the IPP Model & Semantics and the Protocol Specification drafts= to the IESG without further delay. Harry Lewis - IBM Printing Systems = From ipp-archive Fri Jan 30 05:34:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 08:59:44 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Fri Jan 30 09:09:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 10:14:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 10:19:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 11:01:34 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 11:19:49 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Fri Jan 30 11:19:51 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Fri Jan 30 11:19:52 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 11:19:54 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 11:24:50 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 th= ree drafts as Informational RFCs without further delay. Carl Kugler - IBM Printing Systems = From ipp-archive Fri Jan 30 11:50:00 1998 Return-Path: ipp-owner 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-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk 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. =20 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=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 ************************************************************ >>> 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-archive Fri Jan 30 12:10:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 14:40:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 14:50:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 16:10:27 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Fri Jan 30 16:15:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 16:49:02 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Fri Jan 30 17:00:29 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Fri Jan 30 17:10:31 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Fri Jan 30 17:24:02 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Fri Jan 30 18:15:30 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Jan 30 21:35:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 2 04:56:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 2 08:16:07 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 2 11:11:09 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 tran= smit 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 reque= st, to > the whole job is received? The server should respond to the request before accepting appended docu= ment 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 s= erver 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 th= e 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-archive Mon Feb 2 12:48:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 2 14:11:11 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 2 17:11:13 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Attributes with type 4 keywords also allow the 'name' attribute syntax = for administrator defined names. Keywords SHALL be in U.S. English, but at= tributes that are indicated to have the 'name' attribute syntax also automatical= ly have the 'nameWithLanguage' attribute syntax. So in general, attributes with type 4 keywords can use the Language Ove= rride Mechanism? -Carl = From ipp-archive Mon Feb 2 19:36:14 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 2 21:11:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 00:26:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 11:56:23 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Is the approach in Network Working Group Ari Luoton= en Request for Comments: XXXX Netscape Communications Corporati= on Category: Informational September, 19= 97 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 t= o work with a particular proxy, and the IPP client is attempting communication with a TLS-based printer URI, we might need to indicate i= n 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-archive Tue Feb 3 12:58:34 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 13:11:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 13:11:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 14:15:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 14:16:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 14:26:30 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Tue Feb 3 14:41:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 16:06:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 16:32:41 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 16:41:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 16:46:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 16:46:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Tue Feb 3 18:21:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 18:31:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 18:39:57 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 20:01:33 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 20:06:33 1998 Return-Path: ipp-owner 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 Precedence: bulk I believe that "mailto" can include session-based connectivity if it's available. Larry -- http://www.parc.xerox.com/masinter From ipp-archive Tue Feb 3 20:06:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 20:06:37 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 20:11:34 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Tue Feb 3 21:21:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 3 23:26:46 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 coul= d result in a lot of e-mail! Harry Lewis - IBM Printing Systems = From ipp-archive Tue Feb 3 23:56:47 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 03:56:49 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 07:31:50 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 08:41:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 11:41:53 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > 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 proc= ess 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 wil= l only read that much content from the connection before the next request is i= ssued. You might be able to fake around these obstacles by using chunked trans= fer encoding in the response. However, I think this would be considered ab= use 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 mod= el and protocol. The client polls with Get-Job-Attributes looking at job-stat= e, job-state-reasons, and/or job-state-message. After processing is compl= ete, 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 t= he 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-archive Wed Feb 4 12:02:12 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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, mus= t 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 trans= mission 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 clo= se 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-archive Wed Feb 4 12:41:53 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 HT= TP 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 t= he asymmetry of the protocol? As currently constituted a printer cannot se= nd an unsolicted message to anybody. Was this discussed later on on the Thursday brainstorm? = From ipp-archive Wed Feb 4 12:41:54 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 13:17:22 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk We need to decide if our investigation should include polling (only) so= lutions > 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-archive Wed Feb 4 13:22:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 14:16:55 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Randy- UDP datagram notificaton still has the firewalls and proxies problem, u= nless 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 bette= r 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-archive Wed Feb 4 14:26:56 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Wed Feb 4 14:26:57 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 15:02:09 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 15:17:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 15:57:17 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 16:12:00 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 firew= all >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 ma= ny 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 th= inking Internet, an e-mail message for job complete is appropriate and accepta= ble. 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 an= d streamline method should be considered. In PWG IPP, we need to address BOTH! Harry Lewis - IBM Printing Systems = From ipp-archive Wed Feb 4 16:12:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 16:12:04 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 16:12:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 16:22:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Wed Feb 4 17:02:15 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Wed Feb 4 17:27:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 18:22:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 20:02:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 21:32:47 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Wed Feb 4 22:02:48 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 22:37:49 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 22:51:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 22:52:50 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 22:57:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 23:07:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 4 23:07:53 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Thu Feb 5 08:28:07 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Jay, I think SENSE has been more of a topic of discussion at printer MIB mee= tings. 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 t= his > 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 t= opic. > 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-archive Thu Feb 5 09:13:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 10:23:09 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 10:31:11 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 11:13:11 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk But... Proxies don't open up TCP or UDP pipes. Proxies pass nothing th= rough. Everything gets pulled up to the application level and then resent. Mu= ch 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-archive Thu Feb 5 11:18:10 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 11:43:14 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > 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 asynchron= ous notifications outside the IPP box, as proprietary extensions. Later, t= he IPP v2 working group can look at what works and select or synthesize some a= pproach 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. W= ith HTTP/1.1, the client will be polling over a persistant connection, so t= he overhead should be low. Polling rates could be fairly slow, since ther= e'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 'natur= al' use of HTTP) precludes the core IPP protocol from generating asynchrono= us or unsolicited reverse messages. This is a major limitiation - I want to b= e sure that everybody knows that we are doing it and that we all accept t= he trade-off. I'm sure we could invent lots of hacks later on the will wor= k 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 bett= er 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-archive Thu Feb 5 12:08:11 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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. M= ight be on travel or has more important business. Might have to go off-line. (Client workstation from where the job was submitted mig= ht 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 authorizatio= n 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 pendin= g. Presumably job is not huge. 3) User wants confirmation as soon as print is complete, but print= er is being heavily used as determined by queue and pending job sizes= From ipp-archive Thu Feb 5 12:13:10 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 12:53:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 12:58:12 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 13:08:12 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > 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 asynchron= ous notifications outside the IPP box, as proprietary extensions. Later, t= he IPP v2 working group can look at what works and select or synthesize some a= pproach 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. W= ith 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 ther= e'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 'natur= al' use of HTTP) precludes the core IPP protocol from generating asynchrono= us or unsolicited reverse messages. This is a major limitiation - I want to b= e sure that everybody knows that we are doing it and that we all accept t= he trade-off. I'm sure we could invent lots of hacks later on the will wor= k 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 bett= er 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-archive Thu Feb 5 14:33:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 14:48:13 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Thu Feb 5 15:53:15 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Randy- By "proxy", I mean "proxy server", specifically "application-level prox= y server" or "gateway": a server that receives requests intended for ano= ther 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 operat= e at the upper levels of the protocol stack (i.e., all the way up to the applica= tion 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 r= equests, another for FTP requests, and so on. Circuit-level gateways (e.g., SOC= KS, rfc1928) provide a controlled network connection between internal and = external systems. A virtual "circuit" exists between the internal client and th= e 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. Re= sponses 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 th= e internal systems. In general the only packets allowed back through a = proxy server are those that return responses to requests from inside the fire= wall. I think the type of firewall you're discussing is the router based pack= et filtering type (screening router), which works in the lower layers of t= he network protocol stack. It would be interesting to know the install ba= se of the various types of firewalls. I know here at IBM we use proxy server= s (now mostly SOCKS gateways, formerly mostly application proxies). If use a protocol other than HTTP as a transport for realtime asynchron= ous notification, won't we lose the advantages that we gained by chosing HT= TP 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-archive Thu Feb 5 16:38:17 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 16:53:17 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 17:18:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 19:13:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 5 19:18:19 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Persistent connections are really the domain of the HTTP transport laye= r, 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 re= sources 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 roun= d trip delays, results in more network traffic from overhead (SYN, ACK, FIN) t= han 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-archive Fri Feb 6 01:13:24 1998 Return-Path: ipp-owner 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 Precedence: bulk This message is just to reaffirm my motion from the Maui meeting to "last call" our current documents... Randy From ipp-archive Fri Feb 6 05:43:27 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Fri Feb 6 11:28:31 1998 Return-Path: ipp-owner 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-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk 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-sv= rloc-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=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 ************************************************************ >>> 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-archive Fri Feb 6 11:58:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 12:23:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 12:47:46 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 12:48:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 12:48:40 1998 Return-Path: ipp-owner 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@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 Precedence: bulk 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-archive Fri Feb 6 14:53:33 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 15:58:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 16:38:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 16:48:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 17:20:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 21:28:37 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 21:28:39 1998 Return-Path: ipp-owner 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 Precedence: bulk [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-archive Fri Feb 6 21:28:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 21:48:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 6 23:08:44 1998 Return-Path: ipp-owner 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 Precedence: bulk :: >> 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-archive Sat Feb 7 13:18:51 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21897 for ipp-outgoing; Sat, 7 Feb 1998 13:15:53 -0500 (EST) Message-ID: <34DCA4CA.498FD46C@underscore.com> Date: Sat, 07 Feb 1998 13:15:38 -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> Consensus on sending our drafts to the IESG References: <5CEA8663F24DD111A96100805FFE6587030BC21E@red-msg-51.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Sat Feb 7 13:33:52 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA21984 for ipp-outgoing; Sat, 7 Feb 1998 13:33:19 -0500 (EST) Message-ID: <34DCA8E3.C61CF819@underscore.com> Date: Sat, 07 Feb 1998 13:33:07 -0500 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> Re: How should the server behave References: <19980207040246.3716.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk 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 ipp-archive Sun Feb 8 15:49:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sun Feb 8 17:07:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Mon Feb 9 09:34:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 09:34:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 11:09:22 1998 Return-Path: ipp-owner 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 Precedence: bulk [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-archive Mon Feb 9 11:14:22 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 11:49:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 12:49:26 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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. M= y only intent is to minimize the discussion regarding firewalls. (This discussion (firewalls) appears to be making very little progress.) The= re is still a significant amount of work remaining to complete the IPP notification effort. Comments invited! Ron Bergman Dataproducts Corp. = From ipp-archive Mon Feb 9 12:59:26 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > We also discussed that a server MAY keep a list of clients that are t= rying > 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 "h= ang" indefinitely. > Then the > client doesn't receive an error (except if the "queue" is filled). T= his > 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 cl= ient could then give a user the choice of canceling, retrying, or queuing lo= cally and retrying after delay. At that point the user might decide to try a= nother 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-jo= b >> 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/9= 8 08:41 We also discussed that a server MAY keep a list of clients that are try= ing to connect in a "queue", and then serve each one one at a time. Then t= he client doesn't receive an error (except if the "queue" is filled). Thi= s gives the end-user a much happier experience. I think that both approaches should be put into the FAQ. Tom = From ipp-archive Mon Feb 9 13:29:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Mon Feb 9 13:39:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 13:54:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Mon Feb 9 14:14:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 15:06:50 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 15:06:58 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I'm confused about part of the thread which was "IPP> Consensus on send= ing 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 propose= d >something called SIMPLE web printing based on what we were building - = that >just did job submission. That eventually evolved into what we have tod= ay. ... and other job related issues that could be addressed (i.e. Monitori= ng and Management). >Now we move on to address the issues that were lurking in the backgrou= nd - >printer discovery, feature dicsovery , configuration discovery, managm= ent, >notification, flow control, peer queuing,.... (things for s/w to print= er >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 acheiveab= le >(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 tha= t there has been a sideband approach to job monitoring in co-development for ov= er two years. When the SNMP Job MIB project started, we promptly acknowledged the nee= d for submission standards. In late 1995, I lobbied for a job submission "wra= pper" to encapsulate submission attributes (i.e. job submission standard) to fac= ilitate monitoring via the MIB. This was ill received and it wasn't until submi= ssion via the Internet became an issue that we had the opportunity, finally, = to correlate the monitoring channel with submission. At first, I was conce= rned 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 i= nternet 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 r= elates to print jobs. Most of the criticism relates to the unreliable nature o= f UDP and the lack of registration and trap direction. SNMPv3 begins to addre= ss 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 h= ave remained for the Friday JMP meeting. Most of the interested parties hav= e indicated that their private implementations or prototypes of the stand= ard have ALL resorted to some proprietary event mechanism (i.e. Job Traps) to ge= t 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, co= rrelated 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 c= learly NOTIFICATION! Harry Lewis = From ipp-archive Mon Feb 9 16:49:34 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk The 0x0502 status code means "The IPP object is currently unable to han= dle 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-archive Mon Feb 9 16:59:34 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 17:04:36 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 sugges= ted by Charles Gordon in another thread (Three Types of Notification). >2. Notifying the intended receiver of the job that he has a new job a= t >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. M= y only intent is to minimize the discussion regarding firewalls. (This discussion (firewalls) appears to be making very little progress.) The= re is still a significant amount of work remaining to complete the IPP notification effort. Comments invited! Ron Bergman Dataproducts Corp. = From ipp-archive Mon Feb 9 17:20:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 17:20:41 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 9 18:47:25 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 issu= es live in both of the interfaces above. Note that I am not necessarily talking about 3 separate boxes, merely t= hree separate logical entities. I beleive that any printing model that refuses to recognized the existe= nce 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-archive Mon Feb 9 18:55:38 1998 Return-Path: ipp-owner 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 Precedence: bulk #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-archive Mon Feb 9 19:07:17 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 10:54:54 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 11:51:42 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 11:52:01 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Tue Feb 10 12:04:23 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Tue Feb 10 13:09:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 13:50:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 14:19:58 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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 ipp-archive Tue Feb 10 15:05:00 1998 Return-Path: ipp-owner 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 Precedence: bulk Just in case, why not make you reservations to arrive mid-afternoon? Don From ipp-archive Tue Feb 10 15:59:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 16:10:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 16:22:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 17:35:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 17:55:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 18:00:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 18:10:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 18:15:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 18:25:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 19:00:12 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 W= IDELY ADOPTED. Otherwise, it can be argued that the enterprise is already ful= l of host-to-device protocols for network printing, some of which are defact= o 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, toda= y. When I addressed standardizing submission to the device with my late 19= 95 presentation on a "job information wrapper" (possibly a first step towa= rd a *standard* full function network printing protocol), it became clear to= me that members saw no need to depart from their traditional methods of supplyi= ng data to the printer. This resulted in the need for a "mapping document" to a= ccompany the Job MIB and the mapping is fairly sparse in most cases. I'm probably just pointing out what is already implied in your statemen= t. 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 pote= ntial 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 reall= y > robust protocol for interfacing to printers (and I mean the real hard= ware > 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 initia= lly > 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-archive Tue Feb 10 19:08:44 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 reall= y > robust protocol for interfacing to printers (and I mean the real hard= ware > 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 initia= lly > 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-archive Tue Feb 10 19:15:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 19:15:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 19:40:30 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 20:15:36 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 21:05:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 21:21:04 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 21:21:10 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 10 23:07:04 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 00:56:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 01:11:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 01:16:49 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 03:31:46 1998 Return-Path: ipp-owner 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 Precedence: bulk >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-archive Wed Feb 11 03:46:46 1998 Return-Path: ipp-owner 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 Precedence: bulk >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-archive Wed Feb 11 04:21:48 1998 Return-Path: ipp-owner 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" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I am not sure this List is a correct place for such information, bu= t still. We developed a product for mail, fax and Internet fax solution, which supports Delivery Status Notifications and Message Dispositio= n = Notifications in a rather nice fashion, basing on our own technolog= y. 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 t= o >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-archive Wed Feb 11 08:21:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 10:16:52 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 10:21:52 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 10:31:53 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20984 for ipp-outgoing; Wed, 11 Feb 1998 10:31:07 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEBF@EXCHANGE> From: "Wagner, William" To: "'pthambid@okidata.com'" , ipp@pwg.org Subject: RE: IPP> Does the world need a robust host-to-device network Date: Wed, 11 Feb 1998 10:29:31 -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 Precedence: bulk You bring up a point which has, to my mind, been a continuing area of confusion. IPP was originated, among other things, as a replacement to LPD/LPR (which is a local, intranet ... thing). It was, to my understanding, always intended that IPP serve as an intranet as well as in internet protocol. I think it would be beneficial to get the consensus on whether IPP is Internet only, or is intended to be used on any network supporting IP. However, the IETF appears to doubt that an intranet exists, and if it does, believes that it is of no concern to the IETF. Therefore, the IPP has had many requirements added because of internet type considerations (such as security). Because of the Internet focus of the IETF and the resulting burden the IPP spec places on the IPP server, we have seriously considered the option to implement, in addition to a full IPP, an IPP compatible (but perhaps not fully conforming) embedded server that was intended for just the intranet. That is, something that had the same set of user features and would operate with the same user interface as the full IPP, but which was intended for the 95% (or better) of printing that does not involve going outside firewalls. I agree that an IPP which is intended just as a FAX type message transmission capability is hardly worth the effort or attention that IPP has received. If that was the intent, I would agree with those who early on said that the IETF FAX and IPP efforts should be co-ordinated if not combined. As to whether an intranet protocol should cover "all aspects of a distributed printing system", that may still be pursued. But the effort had to start somewhere and a submission/delivery protocol did seem to be the best place to start. W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: pthambid@okidata.com [SMTP:pthambid@okidata.com] > Sent: Wednesday, February 11, 1998 7:56 AM > To: ipp@pwg.org > Subject: Re: IPP> Does the world need a robust host-to-device > network > > > 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-archive Wed Feb 11 10:56:55 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA21082 for ipp-outgoing; Wed, 11 Feb 1998 10:55:28 -0500 (EST) From: Carl Kugler To: Cc: Subject: Re: IPP> IPP > FAQ - How should the server behave? Message-ID: <5030100017320671000002L012*@MHS> Date: Wed, 11 Feb 1998 10:52:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > Is IPP currently defined such that the "server-error-service-unavaila= ble" > (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-unavailabl= e" (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 h= andle the > request due to a temporary overloading or maintenance of the IPP obje= ct. " 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) wit= h 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 queuin= g locally > > and retrying after delay. At that point the user might decide to t= ry 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-archive Wed Feb 11 11:01:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 11:12:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 11:27:37 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 11:27:40 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22200 for ipp-outgoing; Wed, 11 Feb 1998 11:22:30 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol? Date: Wed, 11 Feb 1998 08:22:39 -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 Precedence: bulk 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? 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. What I would like to avoid is producing yet another printing protocol (YAPP). 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. 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. Just my $0.02 Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, February 11, 1998 8:01 AM To: Turner, Randy Cc: 'ipp@pwg.org' Subject: Re: IPP> Does the world need a robust host-to-device network printing protocol? 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-archive Wed Feb 11 11:42:17 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA22810 for ipp-outgoing; Wed, 11 Feb 1998 11:41:03 -0500 (EST) Message-ID: <34E1D466.FB6EBC69@underscore.com> Date: Wed, 11 Feb 1998 11:40:06 -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> MOD> A New View of Notification Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk Randy, > 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. It feels kinda funny to be placed on the "complex" side of the fence after espousing "simple,simple,simple" for so long... ;-) Actually, I didn't view the notion of multiple target URIs as being complex. However, if you get the feeling it is, perhaps you can offer some insights as to why you think it is complex? Part of the complexity that might arise has to do with notifications destined for human readability (ie, natural language email msgs), versus machine-processable notifications for programmatic use. > 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... Sorry, but I feel compelled to toss in my 2cents worth here... The Printer MIB came into being because customers were (literally) clammering for SNMP support in all network devices. IMHO, most (if not nearly all) of those customers didn't really know what they were getting into. SNMP had become the ultimate network management buzzword of the early '90s. Customers (and, to a very large extent, printer vendors) expected printers to be managed via Network Management System (NMS) platforms, such as OpenView, Spectrum, Solstice, etc. The premise was quite simple: "We have invested mucho cash to acquire NMS capabilities, so now we want to leverage that investment to monitor/manage network printers in the same vein." What printer vendors didn't realize--and customers didn't admit unless pushed right up against the wall--is this simple fact: The primary roles for NMS platforms is to manage "network elements" (routers, hubs, gateways, etc). Operations personnel responsible for managing such network elements indeed use the high-powered NMS products to achieve that objective. However, those very same personnel almost NEVER are responsible for network printer management (and, in fact, really hate network printers altogether). NMS products are very costly (for very good reasons), and as a result, the personnel actually responsible for managing network printers could never justify the cost to acquire their own NMS capabilities just for network printer management. Suffice to say, network management personnel really didn't want the network printer personnel using their tools (and asking them to configure things for them, etc). The picture I have just painted can be seen anywhere, at least within the continental USA. Interestingly, Chris Wellens admitted this situation after she personally went out and polled a number of her NMS friends a while back. And we see it in virtually every customer site we step into. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Wed Feb 11 11:52:19 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 11:52:26 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA23179 for ipp-outgoing; Wed, 11 Feb 1998 11:51:57 -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: Wed, 11 Feb 1998 08:51: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 Precedence: bulk I was addressing complexity in the context of having half a dozen different attributes called xx-uri-notify yyy-uri-notify aaa-uri-notify, not necessarily that a single URI may be multi-valued. I wasn't clear about that in my previous message. I was just suggesting that we solve the problem (about 99 percent of the problem) with a single attribute. Having this attribute be multi-valued I don't think is major additional complexity. Also, your comments addressing SNMP are attacking the software applications, and not the protocol. I would agree that generic NMSes and the administrators that use them really don't "get" the printer MIB yet either. Its usually a different crowd (the router, hub, and switch crowd). However, the lack of decent application support doesn't necessarily damn the protocol and MIB support. There is software from HP, Lexmark, and other vendors in Europe that actually make use of SNMP and the printer MIB. I don't think we should dismiss SNMP and MIB support in light of what we consider poor application support by generic NMS vendors or short-sighted administrators. Maybe we haven't done a good job of PR for the Printer MIB, I'm not sure why the "killer printer mib app" hasn't happened yet. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, February 11, 1998 8:40 AM To: Turner, Randy Cc: 'ipp@pwg.org' Subject: Re: IPP> MOD> A New View of Notification Requirements Randy, > 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. It feels kinda funny to be placed on the "complex" side of the fence after espousing "simple,simple,simple" for so long... ;-) Actually, I didn't view the notion of multiple target URIs as being complex. However, if you get the feeling it is, perhaps you can offer some insights as to why you think it is complex? Part of the complexity that might arise has to do with notifications destined for human readability (ie, natural language email msgs), versus machine-processable notifications for programmatic use. > 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... Sorry, but I feel compelled to toss in my 2cents worth here... The Printer MIB came into being because customers were (literally) clammering for SNMP support in all network devices. IMHO, most (if not nearly all) of those customers didn't really know what they were getting into. SNMP had become the ultimate network management buzzword of the early '90s. Customers (and, to a very large extent, printer vendors) expected printers to be managed via Network Management System (NMS) platforms, such as OpenView, Spectrum, Solstice, etc. The premise was quite simple: "We have invested mucho cash to acquire NMS capabilities, so now we want to leverage that investment to monitor/manage network printers in the same vein." What printer vendors didn't realize--and customers didn't admit unless pushed right up against the wall--is this simple fact: The primary roles for NMS platforms is to manage "network elements" (routers, hubs, gateways, etc). Operations personnel responsible for managing such network elements indeed use the high-powered NMS products to achieve that objective. However, those very same personnel almost NEVER are responsible for network printer management (and, in fact, really hate network printers altogether). NMS products are very costly (for very good reasons), and as a result, the personnel actually responsible for managing network printers could never justify the cost to acquire their own NMS capabilities just for network printer management. Suffice to say, network management personnel really didn't want the network printer personnel using their tools (and asking them to configure things for them, etc). The picture I have just painted can be seen anywhere, at least within the continental USA. Interestingly, Chris Wellens admitted this situation after she personally went out and polled a number of her NMS friends a while back. And we see it in virtually every customer site we step into. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Wed Feb 11 12:02:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 12:02:24 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 12:12:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 12:12:29 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 12:32:28 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA24098 for ipp-outgoing; Wed, 11 Feb 1998 12:27:20 -0500 (EST) Message-Id: <3.0.1.32.19980211091811.0096e630@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Feb 1998 09:18:11 PST To: Jay Martin , Carl-Uno Manros From: Carl-Uno Manros Subject: Re: IPP> ADM - How to follow up on IESG comments on IPP Cc: ipp@pwg.org In-Reply-To: <34E1BF52.F335A715@underscore.com> References: <3.0.1.32.19980210160822.00cddc10@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk At 07:10 AM 2/11/98 PST, Jay Martin wrote: >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 -- >---------------------------------------------------------------------- > > Jay, 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... Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Wed Feb 11 12:32:41 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I think would be a good idea to define a new *status* code for this pur= pose. It could be an informational code, rather than an error code, if this c= ondition is considered normal. It might also be worthwhile to invent an attribu= te 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-unavai= lable" > > (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-unavaila= ble" > (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 ob= ject. " > 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) w= ith 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 queu= ing 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-archive Wed Feb 11 12:42:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 15:40:54 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Wed Feb 11 15:41:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 16:01:45 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA03881 for ipp-outgoing; Wed, 11 Feb 1998 15:36:18 -0500 (EST) Date: Wed, 11 Feb 1998 15:36:18 -0500 (EST) From: ipp-owner Message-Id: <199802112036.PAA03881@lists.underscore.com> From ipp-archive Wed Feb 11 16:10:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 16:20:15 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05151 for ipp-outgoing; Wed, 11 Feb 1998 16:15:35 -0500 (EST) Message-ID: <34E2149B.ECA1563A@underscore.com> Date: Wed, 11 Feb 1998 16:14:03 -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: IPP> What ever happened to IEEE 1284.1 (aka TIPSI, aka NPAP)? References: <5CEA8663F24DD111A96100805FFE6587030BC233@red-msg-51.dns.microsoft.com> <34E0DA3E.FAFF26F9@underscore.com> <34E1FEE0.37BC0515@dazel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: bulk 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? Following Jim's comment, 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, citing that "SNMP was the proper method for printer management"; 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. 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... Incidentally, if anyone is interested in participating in an effort to define/design/implement a truely open network printing protocol, you should first read the TIPSI spec; various forms of the spec can be found on this public server: ftp://ftp.lexmark.com/pub/ieee/1284.1/ If nothing else, it serves as an *excellent* starting point for a network printing 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-archive Wed Feb 11 19:56:26 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00338 for ipp-outgoing; Wed, 11 Feb 1998 19:28:09 -0500 (EST) Message-Id: <3.0.1.32.19980211153128.00b40b70@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Feb 1998 15:31:28 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> ADM - Cut-off dates for IETF meeting in LA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk FYI, here are the cut-of dates for LA: March 9 - Working Group scheduling closes at 1700 EST March 13 - Internet Draft submission cutoff date at 1700 EST March 20 - Pre-Registration Payment cutoff date at 1200 EST March 25 - Pre-Registration cutoff date at 1200 EST March 25 - Working Group agendas due date by 1200 EST March 25 - Registration Cancellations cutoff date by 1800 EST Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From ipp-archive Wed Feb 11 19:56:31 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00354 for ipp-outgoing; Wed, 11 Feb 1998 19:28:29 -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: IPP> 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: ipp-owner@pwg.org Precedence: bulk > 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-archive Wed Feb 11 19:56:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 19:56:39 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00400 for ipp-outgoing; Wed, 11 Feb 1998 19:35:46 -0500 (EST) Message-Id: <3.0.1.32.19980211163141.0099a290@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Feb 1998 16:31:41 PST To: Roger K Debry , From: Carl-Uno Manros Subject: Re: IPP> Notification Requirements In-Reply-To: <5030100017270909000002L092*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Wed Feb 11 19:56:44 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00365 for ipp-outgoing; Wed, 11 Feb 1998 19:30:27 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC253@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'iesg@ietf.org'" Cc: "'ipp@pwg.org'" Subject: IPP> IPP Last Call Date: Wed, 11 Feb 1998 14:27:53 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Precedence: bulk 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 ipp-archive Wed Feb 11 19:56:48 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00395 for ipp-outgoing; Wed, 11 Feb 1998 19:35:39 -0500 (EST) Message-ID: <5CEA8663F24DD111A96100805FFE6587030BC256@red-msg-51.dns.microsoft.com> From: Paul Moore To: "'Keith Moore'" Cc: iesg@ns.ietf.org, ipp@pwg.org Subject: IPP> RE: IPP Last Call Date: Wed, 11 Feb 1998 16:19:32 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: ipp-owner@pwg.org Precedence: bulk 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 ipp-archive Wed Feb 11 19:58:40 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 11 19:58:55 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA00435 for ipp-outgoing; Wed, 11 Feb 1998 19:40:22 -0500 (EST) Message-ID: <6FCC2B3BA67BD111A47D0060089D281508AEC7@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:11:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: ipp-owner@pwg.org Precedence: bulk I must have missed something here. It was my understanding that IPP 1.0 was specifically intended as at least the first step to a robust, full-featured network printer interface. The origins of IPP included the intention of replacing LPD/LPR and that was one of the basic requirements. The Internet provided some glitz, but a printing protocol just for the Internet is a niche product compared with supporting local printing. However, if your position was "we need two things, something to provide high level features for users on the Internet, [and] something to fix the 'LPD sucks' problem", I could understand the lack of enthusiasm since the intention was that IPP address both of these requirements. Why you feel that these to requirements are mutually exclusive? W. A. Wagner (Bill Wagner) OSICOM/DPI > -----Original Message----- > From: Paul Moore [SMTP:paulmo@microsoft.com] > Sent: Wednesday, February 11, 1998 12:04 PM > 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? > > 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-archive Wed Feb 11 20:21:56 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00871 for ipp-outgoing; Wed, 11 Feb 1998 20:13:10 -0500 (EST) Content-return: allowed Date: Wed, 11 Feb 1998 13:48:21 PST From: "Caruso, Angelo " Subject: RE: IPP> Does the world need a robust host-to-device network prin tingprotocol? To: "'Jay Martin'" , Paul Moore 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 Precedence: bulk I also agree that a robust host-to-device printing protocol is far more valuable than what IPP has evolved to. Other than enabling some minimal bi-directional driver capability (mostly enabled by the existing Printer MIB) and some job monitoring capability (also enabled by a PWG MIB which was nearly complete before IPP started), I've never quite understood what value IPP really brings to the customer. Pushing a print job through a firewall doesn't seem that important to me. My view of distribute and print is: distribute electronically, then let the recipient decide if the document is worthy of their local printing resources. Angelo -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, February 11, 1998 12:39 PM To: Paul Moore Cc: ipp@pwg.org Subject: Re: IPP> Does the world need a robust host-to-device network printingprotocol? 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-archive Wed Feb 11 20:32:11 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA00882 for ipp-outgoing; Wed, 11 Feb 1998 20:14:21 -0500 (EST) From: Keith Carter To: , , , , Subject: IPP> 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: ipp-owner@pwg.org Precedence: bulk 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-archive Wed Feb 11 23:18:07 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 02:05:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 02:05:49 1998 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA14774 for ipp-outgoing; Thu, 12 Feb 1998 02:02:12 -0500 (EST) Message-ID: From: "Turner, Randy" To: "'Jay Martin'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> IPP > FAQ - How should the server behave? Date: Wed, 11 Feb 1998 23:01: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 Precedence: bulk In my contention analysis comments (see earlier PDF posting) I make this suggestion as well. Randy -----Original Message----- From: Jay Martin [SMTP:jkm@underscore.com] Sent: Wednesday, February 11, 1998 8:42 AM To: ipp@pwg.org Cc: Carl Kugler 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-archive Thu Feb 12 03:16:17 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 07:16:21 1998 Return-Path: ipp-owner 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 Precedence: bulk TEST MESSAGE ONLY. PLEASE IGNORE. From ipp-archive Thu Feb 12 08:02:58 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 ipp-archive Thu Feb 12 09:02:56 1998 Return-Path: ipp-owner 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 Precedence: bulk ---------------------- 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-archive Thu Feb 12 09:42:56 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 09:56:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 10:37:56 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I agree with this point... >The main point I am trying to make... is that the IPP server should no= t >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 messag= es 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-archive Thu Feb 12 10:37:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 11:10:34 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 11:10:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 11:10:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 11:48:01 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 11:53:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 11:58:02 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 12:28:04 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 12:43:03 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Thu Feb 12 13:28:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 13:28:04 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 14:03:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 14:58:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 16:04:56 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 16:18:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 16:31:41 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk > 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 si= ngle connection. (Not that HTTP makes any use of it, but telnet does.) "The= asynchronous or "out-of-band" notification will allow the application t= o go into 'urgent mode', reading data from the TCP connection. This allows c= ontrol commands to be sent to an application whose normal input buffers are fu= ll 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 diffe= r > 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-archive Thu Feb 12 16:40:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 16:40:00 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 16:57:55 1998 Return-Path: ipp-owner 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 Precedence: bulk > 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-archive Thu Feb 12 17:09:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 18:08:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 18:17:57 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Thu Feb 12 18:31:20 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 18:38:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 18:46:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Thu Feb 12 18:53:00 1998 Return-Path: ipp-owner 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 Precedence: bulk > -----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 ipp-archive Thu Feb 12 19:08:07 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 19:38:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 20:29:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 12 23:33:52 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 Ne= tware (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 a= dapt to a Netware paradigm? I would think the other way around. Harry Lewis - IBM Printing Systems = From ipp-archive Fri Feb 13 02:58:10 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 06:36:42 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 06:54:48 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 10:30:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 10:46:05 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 11:49:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 12:43:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 12:59:57 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 13:11:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 14:48:23 1998 Return-Path: ipp-owner 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 Precedence: bulk [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-archive Fri Feb 13 15:04:59 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 15:19:53 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I agree with Randy but the diametric views being expressed have me conc= erned. 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 wit= h IPPv1 all around? On the concern that the Host-Printer protocol will be constrained to th= e 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-archive Fri Feb 13 15:33:57 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Fri Feb 13 15:58:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 15:58:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 16:15:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 16:29:47 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 16:31:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 17:10:28 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 17:26:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 18:08:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 18:32:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 13 18:49:38 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sun Feb 15 20:43:59 1998 Return-Path: ipp-owner 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" Content-Transfer-Encoding: quoted-printable 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 Precedence: bulk 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. =20 Are the printer vendors active PWG members?=20 What am I missing? Thanks, David Spencer=20 ____________________________________________ 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-archive Mon Feb 16 08:09:06 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 16 12:14:15 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 16 14:30:07 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 16 20:09:19 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 09:49:51 1998 Return-Path: ipp-owner 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 Precedence: bulk --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-archive Tue Feb 17 10:04:52 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Tue Feb 17 10:29:51 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 10:38:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 12:19:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 12:32:49 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 13:02:50 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 dire= ctories. 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 functionalit= y. 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 partic= ularly troublesome example, is a bad idea. We, as a group of individuals, sug= gest that the default requirement for new HTTP functionality must be to crea= te a new method name. Internet-Drafts are available by anonymous FTP. Login with the usernam= e "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-archive Tue Feb 17 13:04:31 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Too bad the Hypermail archives don't do something useful with the attac= hments. 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 poin= ter to its location on the ftp server is the best approach. That way if you c= an look at it from your e-mail directly you can, otherwise you can retriev= e 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-archive Tue Feb 17 13:12:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 13:12:59 1998 Return-Path: ipp-owner 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 Precedence: bulk -----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 Precedence: bulk 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-archive Tue Feb 17 13:23:03 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 13:39:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 13:49:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 14:49:32 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Tue Feb 17 17:00:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 17:04:35 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 17:14:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 17:19:52 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk Yet, in January 1998, an overwhelming majority expressed their desire t= o 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-archive Tue Feb 17 17:24:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 17 22:44:52 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Wed Feb 18 04:38:11 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 18 09:14:36 1998 Return-Path: ipp-owner 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-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk 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]=20 Sent: Tuesday, February 17, 1998 7:24 AM To: ipp@pwg.org=20 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-archive Wed Feb 18 13:19:39 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 18 13:49:43 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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 S= NMP 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 t= he 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 s= cope in order to make progress). What complexitis of printer management are you referring to which are c= urrently 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 pro= tocol. 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 p= rotocol could be the same between client and server and client and printer. IP= P 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 ob= jective 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 ther= e 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 currentl= y 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-archive Wed Feb 18 19:04:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 18 21:19:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 19 10:34:51 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk I have posted the updates to the updates to the requirements document which reflect the discussion in yesterday's telecon. The text version h= as 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-archive Thu Feb 19 11:49:53 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 19 17:09:58 1998 Return-Path: ipp-owner 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 Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org Precedence: bulk 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-archive Thu Feb 19 17:49:58 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 19 18:05:13 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Thu Feb 19 20:20:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 20 09:30:10 1998 Return-Path: ipp-owner 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 Precedence: bulk >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-archive Fri Feb 20 09:55:23 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 20 10:05:48 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 20 13:15:16 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 20 17:15:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sun Feb 22 09:48:49 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Mon Feb 23 20:46:02 1998 Return-Path: ipp-owner 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@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 Precedence: bulk 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 ipp-archive Tue Feb 24 21:26:20 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Tue Feb 24 21:51:19 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 25 10:22:22 1998 Return-Path: ipp-owner 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 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : 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-archive Wed Feb 25 10:57:26 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Wed Feb 25 14:16:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 25 16:26:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 25 17:36:32 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 25 17:44:58 1998 Return-Path: ipp-owner 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 Precedence: bulk >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-archive Wed Feb 25 17:56:33 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 25 18:21:36 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Wed Feb 25 20:01:34 1998 Return-Path: ipp-owner 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-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ipp-owner@pwg.org Precedence: bulk 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=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 ************************************************************ >>> 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 =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 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-archive Wed Feb 25 21:46:37 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 07:22:08 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 08:16:41 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 08:31:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 10:41:43 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 10:47:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 12:16:44 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 13:02:42 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Thu Feb 26 14:06:45 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 27 20:29:22 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Fri Feb 27 21:28:36 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Feb 28 14:02:18 1998 Return-Path: ipp-owner 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 Precedence: bulk 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 ipp-archive Sat Feb 28 15:37:31 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Feb 28 17:42:25 1998 Return-Path: ipp-owner 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 Precedence: bulk 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-archive Sat Feb 28 20:12:21 1998 Return-Path: ipp-owner 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 Precedence: bulk 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