From ipp-archive Sat Nov 9 14:07:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA01917 for ipp-outgoing; Sat, 9 Nov 1996 14:03:25 -0500 (EST) Date: Sat, 9 Nov 1996 14:03:21 -0500 (EST) From: Super-User Message-Id: <199611091903.OAA01912@lists.underscore.com> To: ipp Subject: IPP test Sender: ipp-owner@pwg.org Precedence: first-class Status: RO agn From ipp-archive Sat Nov 9 14:32:53 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02072 for ipp-outgoing; Sat, 9 Nov 1996 14:31:36 -0500 (EST) Message-ID: <3284DB8C.2781E494@underscore.com> Date: Sat, 09 Nov 1996 14:29:16 -0500 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP test message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Testing. /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 Mon Nov 11 15:27:19 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06529 for ipp-outgoing; Mon, 11 Nov 1996 15:23:59 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 11 Nov 1996 13:22:21 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org, pwg@pwg.org Subject: IPP charter Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At the New Orleans meeting I presented a paper copy of a proposed charter for the Internet Printing Project. This was reviewed on Thursday afternoon. Thursday evening we came up with a new version that I labeled 2.0. Then the next day on Friday, we made some additional changes, I am calling that version 3.0. I have posted all three versions on the ftp.pwg.org server: ftp://ftp.pwg.org/pub/pwg/ipp/charter/charter1.(ps, pdf, txt) ftp://ftp.pwg.org/pub/pwg/ipp/charter/charter2.(ps, pdf, txt) ftp://ftp.pwg.org/pub/pwg/ipp/charter/charter3.(ps, pdf, txt) Version 3.0 is still not in a good final form. It is just a cleaned-up brainstorming list. I hope to work on it in the next few days. I am still open to any suggestions or comments. There was some discussion about what format or style the charter should be in. I believe that this is the exact format for sending the the IETF area directors, and I plan to use this same exact document as a charter for the working group (both informally now as we have organized ourselves, and formally under the IETF). ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ I have included the text below for reference: --------------------------------------------------------------------- Charter 3.0 11/8/96 Internet Printing Project (ipp) ------------------------------- Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: Mailing lists: General Discussion: ipp@pwg.org To Subscribe: majordomo@pwg.org Archive: ftp://ftp.pwg.org/pub/pwg/ipp Editor Scott Isaacson Description of Working Group: This working group will work to solve the following Internet printing problems. All solutions must be platform independent for maximum effectiveness and deployment. Locate and select via a browser - Name - Geographic Location - other attributes - control the scope and or context of searching NOTE: The use of the term Browser is specifically limited to an Internet Web Browser (html, http, Netscape, Internet Explorer, Mosaic, etc.). It does not indicate MIB browsers or other browsers specific to a proprietary product or technology. Install this printer into the native OS - including any printer driver or other support Print: - from any desktop application (spreadsheets, word processors, browsers) - print by reference - inside and outside firewalls - specifying submission attributes at submission time - design for programmatic printing User query of via browser - status and capabilities - printer: number of jobs, position of jobs, status of printer - job: status of job User selection of receiving events or not - job completed, job affectin printer status change, job status change - own jobs only? jobs affecting this job? - How are events delivered (e-mail, static html pages, live pages) Solution must be platform independent Capability matching - reject if printer can't print the job - find the right printer based on job attributes Cancel Job - Your own job Simple enough for embedding in a network attached printer - A legitimate implementation of this might be able to accept only one Objects - Printer - Jobs - Documents Use but don't invent: Need an authentication mechanism - Prove you are who you are Need an authorization mechanism - Assign a role to the authorized entity V1 = Users V2 = Operators/Administrator Support for electronic commercial transactions (provide for or use existing mechanism) - Payment along with job request - Negotiate the transaction, then get a authorization id back Don't preclude Whatever we do should not preclude the notion of Logical Printers - Allow for fun configurations - Protocol should allow for reporting where the job went (if it was a Logical Printer) Whatever we do should not preclude output devices (fax, printer, repository) Design goals for extensibility: - We need a path for similar extensions to interoperate - We need a way for proprietary extensions to never conflict Keep in mind: Give away the client side! Win hearts and minds - Browsers - Client OSs - NOSs - ISPs - PDLs - Service buereaus Lightweight enough that we can do it in 6 months. Version 2 Suggestions Modify Job Resubmit Job - similar printer (no need to change PDL) - dissimilar level (transform PDL as needed) Simple Operator/Management Commands (possibly V1) - Enable Printer - Disable Printer - Pause Printer - Resume Printer - Manage Roles - Create a Printer - Create and manage template - Cancel any/all jobs Job streaming support (open, write, ..., close) What Internet Printing is NOT: How native OSs *temporarily* install printers Expose HOW this works to the user Don't care about marsahlling, PDLs, etc. No command line Not worry about how to print nested HTML docs (W3C) Not include about Input devices (scan, fax-in) Goals and Milestones: Weekly teleconference. Wednesday Internet-Drafts: No Current Internet-Drafts. Request For Comments: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1759 PS Mar 95 Printer MIB From ipp-archive Mon Nov 11 15:47:18 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06987 for ipp-outgoing; Mon, 11 Nov 1996 15:45:11 -0500 (EST) Message-Id: <2.2.32.19961111204030.00907998@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 12:40:30 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP Mark your Calendars for December 12 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi, I have just got confirmation from Harald Alvestrand that we have the BOF slot. Note his view that ASN.1 will be a hard sell (if we should choose to recommend that). --- Carl-Uno, you've got your BOF scheduled for Thursday, 1300-1500. Please drop any updates to the agenda to me, Keith and agenda@ietf.org. Note that the anti-ASN.1 people will probably be out in force! Harald --- Below is a copy of the Proposed Agenda that I sent Harald before our meeting in New Orleans. I expect that we want to update it in light of our recent discussions. Let us discuss this in the phone conference on Wednesday. -- The purpose of the meeting is to evaluate the need for an Internet Lightweight version of the ISO/IEC Document Printing Application (DPA) access protocol (ISO/IEC 10175:1996). A number of major printer vendors have announced products based on the DPA standard and it would seem desirable to make at least a subset of this functionality available also for use over the Internet and intranets. Initial work on the subject has started in the Printer Working Group (PWG), a group of printer manufacturing companies. This group is previously known to the IETF as the main contributors to the RFC 1759 on the Printer MIB. Proposed Agenda for the LDPA BOF in the IETF San Jose Meeting: Introduction (10 mins) History and Requirements (30 mins) - What is wrong with RC 1179? - What are the current user and technology requirements? - What is the Document Printing Application (DPA)? Presentation of the Lightweight DPA (LDPA) Draft (30 mins) - Presentation of content - Work to date in the Printer Working Group (PWG) Discussion and Resolution of Issues (if possible) (30 mins) - What is the right level of "lightness" for LDPA? - Is there a need to coordinate with other IETF projects, e.g. Fax? - Do we need an RPC mechanism, such as RPC Protocol Spec V2 in RFC 1831? - What protocol marshalling mechanism(s) should be used? Should we use ASN.1/BER (e.g. LDAP), XDR, ASCII, or some other mechanism? - Security Requirements for LDPA? Wrap-up (10 mins) - Summary of discussion - List remaining issues to be resolved - Home work assignments - Make recommendation about further progress in IETF ---- Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 11 16:07:18 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA07113 for ipp-outgoing; Mon, 11 Nov 1996 16:05:38 -0500 (EST) Message-Id: <3.0.32.19961111130302.0072d9a0@crash.cts.com> X-Sender: raylutz@crash.cts.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Mon, 11 Nov 1996 13:04:16 -0800 To: ietf-fax@imc.org From: Raymond Lutz Subject: IPP Re: Revised draft charter Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 09:07 PM 11/8/96 PST, Larry Masinter wrote: >Of the various reasons to split a working group into parts, "separate >applications" is a good reason, "separate expertise" is not. I think >it would be counterproductive to split the group along the lines >suggested by Raymond Lutz. If some folks want to go off and write a >proposal for data formats, they're free to do so, and then we can >review and discuss the proposal here. > >Keep charter as is. I guess I will need to spend some more time explaining this position, since so far, I don't think anyone understands the point. I want to apologise that this can't be condensed into a sound-bite sized email message. Let me remind you that I have very little interest in this issue except that I am attempting to represent what I feel would be the concensus of companies making Multifunction devices. In such devices, there are indeed multiple "applications" and distinct subsystems with customarily separate groups of people operating as experts in those areas. I must say that I rigorously disagree with Larry's point that separating work into separate areas, (sometimes "layering" is the term) is not productive within a given application. I don't think I havee to preach very long to this group for people to agree that the layering concept has been a successful method of suppressing complexity, and allowing groups of people to handle very complex issues by splitting the problem into layers. Do systems always exhibit these layers in implementation? No. They exist for several good reasons, one of which is the reduction of complexity at any one level, and the ability for humans to process complexity. Another benefit is the use of one layers by various other layers. Certainly, it allows groups of "experts" of each layer to exist. Most architects are sold on this idea today. After playing with the MFP problem for the last 3 years, I am not a newcomer to the problem of various expertise groups. In this case, we see another group with very similar agenda starting, the "Internet Printing Protocol" group, based on the idea that internet printing is a separate application that needs a different group. I think this fits Larry's model. So, OK, let's say that we take Larry's approach and use the application as the justification for a separate group doing work which may or may not be similar at all to the work of the ietf-fax mailing list. It is possible that the internet printing protocol group will be working on similar topics, since, let's face it, true "internet fax" is little more than scan-here/print-there. If you are an MFP manufacturer, it is likely that you will be required to support BOTH protocols, MIME and IPP, whatever that winds up being. I know that most makers of these MFP devices are extremely cost sensitive, and so the idea of needing to support both is hogwash, or at least leaves a distinctly bad taste in your mouth regarding the effectiveness of the standards process. If you look at the recent Novell/Xerox proposal of "Light DPA" (LDPA) you see a RPC style protocol with intervening spooler queues. If this is the future of printing, then this doesn't map very well to the simple MIME attachment for fax that apparently is the consensus of this mailing list. I don't see why the MIME protocol improvements (such as comfirmation of receipt, accounting concerns, etc.) can't be equally applied to the "internet printing" problem, especially if we consider the spooler queues in the LDPA model as email transfers of some format, and visualize the LDPA protocol to be oriented to a intranet application. Can we hope that the people in the Printer Working Group will decide that "printing" is no longer a viable application and proceed to support "fax" as the application of choice? Fat chance. Or, turn the problem around, and consider "fax" as "printing" and abolish the ietf-fax list and use only the ipp list. Again, fat chance. To me, the separation of these issues due to the apparant and customary separation of these applications is rediculous. The right direction to go is to separate the LAYERS which all the groups can effectively use. Let's look at this path more closely. As I have asserted previously, the proper split is between PROTOCOL and CONTENT. There are many different contents that should be transportable by the same protocol. We have been discussing T.4 and T.6 (compressed image) formats, but others, such as printer formats are indeed possible as well. Clearly, for the fax application, we need an improved "Content", since I know of no one that considers g3fax to be sufficient. This certainly applies to the "fax" application, and to the support of the installed base of g3 fax devices. Some people have suggested that MIME+SMTP is the protocol to use for this application. I don't think the ipp (LDPA) has the same protocol in mind. But, I don't think this issue has been absolutely decided either either in either forum. If we consider the Internet Printing problem, we would consider that it would be nice to be able to attach a print-oriented file to an email and send it to a printer of a specific IP address. Is this a different "application" from the fax application? Not from this vantage point. It is my hope that splitting the problem along the lines of LAYERING instead of APPLICATION will allow these groups to come together and use a common base of technology instead of two vastly different approaches depending on whether you see the device as a fax machine with a printer inside or a printer that can receive fax format data content. I think some people were thinking that I was proposing that the list mfpa@mfpa.org should be responsible for part of the work. I don't, nor have I ever asserted that position. I was looking for a basis for cooperation among groups of experts in groups that are unlikely to give up their identity. In light of this knowledge, the MFPA attempted to establish web-based forums (http://www.mfpa.org/forums.html) as an experimental method to handle various sub-projects. I haven't been able to resolve all the technical issues with this method yet, but I think that such forums will be a good approach in the future. That resource will continue to be available if we should decide that it is a viable way to handle multiple similar projects. As an experimental approach it is probably too new to start with this project at this time until I work out more of the logistics issues. It is clear to me that DATA CONTENT issues exist for the facsimile application. Improving the format of g3fax for transport as a MIME type is clearly a requirement. Let's not confuse this with the protocol enhancements that can be used for both the facsimile and printing applications. With all this said, I hope you understand my position. I think a split is best at this time to allow both the protocol issues that can be applied both to printing and faxing (probably both using MIME) to be separated from the specific issues with regard to supporting the installed base of g3 fax devices and T.4/T.6 compress image formats. I really don't know what everyone is afraid of. Such mailing lists are created easily and allow nice partitioning of the work. However, I am also a realist, and will settle for possible future split of the work in this fashion. In the meantime, I think I have already achieved a change in the charter, specifically in the list by Larry, in that at least the NUMBERING of the items should be removed. Fair enough? -Raymond From ipp-archive Mon Nov 11 18:22:19 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA08367 for ipp-outgoing; Mon, 11 Nov 1996 18:17:58 -0500 (EST) To: raylutz@cognisys.com CC: ietf-fax@imc.org, ipp@pwg.org In-reply-to: <3.0.32.19961111130302.0072d9a0@crash.cts.com> (message from Raymond Lutz on Mon, 11 Nov 1996 13:04:16 PST) Subject: Re: IPP Re: Revised draft charter From: Larry Masinter Message-Id: <96Nov11.151822pdt."130"@palimpsest.parc.xerox.com> Date: Mon, 11 Nov 1996 14:18:22 PST Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Ultimately, we have to combine the expertise of all of the expert subgroups into a single application. At the present time, there are enough expert subgroups that I don't think we need more to go off and design the pieces, we just need the group that integrates the pieces into a particular application profile. Layering may be useful if you're really trying to solve a complex problem, but I don't think the problem is complex. Let's not make it harder than it is. I agree that 'internet fax' and 'internet distributed printing' are similar; in fact, I think that 'internet distributed printing' is a good start for the necessary protocols for doing real-time fax. On the other hand, printing is different enough from faxing (who owns the printer, is the print unsolicited, what are the accounting & status reporting & privacy requirements) that printing might well wind up with a different application profile than faxing. Let's hope that the differences are all there for a good reason. # As I have asserted previously, the proper split is between PROTOCOL and # CONTENT. There are many different contents that should be transportable by # the same protocol. I agree that PROTOCOL should be split from CONTENT. But don't confuse process ("do we have a separate PROTOCOL and CONTENT group?") with product. # However, I am also a realist, and will settle for possible future split of # the work in this fashion. In the meantime, I think I have already achieved # a change in the charter, specifically in the list by Larry, in that at # least the NUMBERING of the items should be removed. Fair enough? No, not really. I didn't come up with those numbers, they were in Dave Crocker's proposal, I just did wordsmithing. But let me not detract from the glory. Regards, Larry From ipp-archive Mon Nov 11 20:42:22 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA09020 for ipp-outgoing; Mon, 11 Nov 1996 20:40:59 -0500 (EST) Message-Id: <2.2.32.19961112014014.009944a0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 17:40:14 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP Agenda for Teleconference - Wednesday November 13 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The IPP project decided to hold telephone conferences weekly (almost) on Wednesdays, 1 - 3 pm PST, 4 - 6 EST. The first one is coming up this week. To connect to the conference you dial: (423) 544 0905, when prompted enter access code: 114698 My suggestion for Agenda topics this Wednesday: - Review IPP Minutes from New Orleans - Review IPP Charter from New Orleans (expect an improved version by Wednesday morning) - Check on progress of home work assignments: - Subset of DPA attributes to be used as job and printer attributes - Schemas for Directory information about printing - Service Location protocol or LDAP mappings (unfortunately, the minutes do not reflect who volonteered for which home work assignment, but let your concience tell you. Please distribute any results to the DL in advance) - Discuss Agenda for the IETF BOF - Needs to go out after this phone conference (see earlier agenda proposal that I sent to IETF) - Discuss TOC and level of detail for the Internet Draft document If you think that I have left anything important out, drop a message to the DL ASAP. Speak to you soon, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 11 22:02:23 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09519 for ipp-outgoing; Mon, 11 Nov 1996 22:01:53 -0500 (EST) Message-Id: <3.0.32.19961111184222.006b59f0@crash.cts.com> X-Sender: raylutz@crash.cts.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Mon, 11 Nov 1996 18:59:45 -0800 To: Carl-Uno Manros From: Raymond Lutz Subject: Re: PWG IPP charter Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Thanks for your reponse. At 05:02 PM 11/11/96 PST, Carl-Uno Manros wrote: >At 13:15 11.11.96 PST, you wrote: >>The following charter description was posted to the internet printing >>protocol reflector. I hope the overlap between the ietf-fax group and this >>group can be effectively harmonized. >>-Raymond >Ray, > >please note that the charter document is still in very raw format, it needs >better wording and polishing before it is presentable to a wider audience. I consider anything that is published to these sort of "open" discussion lists to be free game. The audience subscribing to the ietf-fax list is probably quite similar in make-up to the ipp list. The ipp list is quite new, and certainly I would hope that the "charter" description would undergo further discussion and refinement. An important note is that the discussion of the scope is most important to get the various groups working on material that is not overlapping in scope, and the work makes sense. I am concerned because the ietf-fax group is working in one direction and the ipp group seems to be working toward another. Indeed, the desired end result for both is quite similar. Many of the items in the charter overlap with those that are stated in the ietf-fax proposal. When I see things like this, I usually worry that things are being done for political rather than technical purposes. >I am interested in finding out what you and others in the IETF Fax group >think are the potentially overlapping areas between the two projects. Shame >you could not make it to New Orleans, you lost out on some of the fun.... Yes, I like New Orleans. But I just finished a big conference and a trip to Japan. So my family was happy to have me here at home for a while. I hope this work is open to review in written form... -Raymond From ipp-archive Mon Nov 11 22:17:22 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA09643 for ipp-outgoing; Mon, 11 Nov 1996 22:12:58 -0500 (EST) Message-Id: <2.2.32.19961112031200.00954a24@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 19:12:00 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP PING for IETF BOF Meeting on December 12 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Fellow IPPers, As you remember from the New Orleans meeting, we need to have at least 20 warm bodies attending the BOF to demonstrate that there is indeed enough interest in this subject to get an IETF project started. We might potentially get a lot more than 20 people, but we have no idea what the agendas are of people who have not been directly or indirectly involved so far; they may well be there to sabotage or delay the project rather than support it. Please send an indication to the DL to confirm your attendance. Even if you are not able to be there in person, you may have somebody else from your organization attending the IETF meeting. If so, try to make sure that they are well briefed and show up for two hours on Thursday at 1 pm in the BOF meeting. Please let me know about that person in advance. Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 12 12:07:33 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10693 for ipp-outgoing; Tue, 12 Nov 1996 12:05:29 -0500 (EST) Message-Id: <2.2.32.19961112170408.00903c84@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 09:04:08 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP The IETF Application Area rules for starting a WG Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I copied the following text from the IETF Application Area Web Page: ---- Starting a working group A working group is started to do work that the IETF thinks should be done. Since you are the IETF, you decide! The steps towards forming a working group are: - Propose the idea to interested people. Often, existing WG lists and other public fora are good for getting things aired. - Convince the Area Directors that it is a good idea. - Write a Charter for the working group. This should contain: - The name and acronym for the WG - One or more proposed chairpersons - The name of the mailing list and its archive - The purpose of the WG: What it will produce, and why - The goals and milestones: When it will produce what it expects to produce. - Proposed editors for any documents to be produced should be shown if possible. If any of these are missing from the charter, it will be rejected summarily; GET IT RIGHT! Mail the charter to both area directors, with a CC to iesg-secretary@cnri.reston.va.us. The area directors then either give feedback or forward it to the IESG and IAB; expect at least 2 weeks to pass before final approval is given. Note that final approval of chairs and editors may be negotiated between the area directors and the proposers and is subject to IESG review. Except in exceptional circumstances, WGs will not be approved with one person acting as both chair and editor of a critical document, nor will WGs be approved when different positions are expected to emerge and the proposed chair is strongly identified with one of the positions. When the IESG has approved the WG, it will be announced on the ietf-announce list. This is the official "creation date" of the WG. If the IESG rejects the charter, the ADs are responsible for telling the proposers why it was rejected. ---- Harald has confirmed that we can start the motions to get a WG formed even before we hold the BOF in San Jose. This means that as soon as we are all happy with the polishing of the Charter we can hand it in. Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 12 12:22:33 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA10884 for ipp-outgoing; Tue, 12 Nov 1996 12:21:56 -0500 (EST) Message-Id: <2.2.32.19961112171942.00918b68@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 09:19:42 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP Additional info about the BOF Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Our BOF meeting is now officially registered. You can see the announcement on the following IETF Web page: http://www.apps.ietf.org/apps/track-sj-dec96.html The deadline for Internet-Drafts into San Jose is November 26. I suggest that we do not wait until the last day! Let us aim to have our document ready by November 22 at the very latest. Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 12 14:27:34 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11167 for ipp-outgoing; Tue, 12 Nov 1996 14:26:06 -0500 (EST) Message-Id: <2.2.32.19961112192002.0093a25c@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 11:20:02 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP Charter - Overlap with IETF Fax? Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Ray Lutz has cross posted some of our IPP messages to the IETF Fax group to invoke discussion about possible overlap between Printing and Fax in the IETF. I asked the Fax group members to indicate to us where they thought the overlap might be. Today the following reply from Dave Crocker, one of the proposed co-chairs of IETF Fax and an Internet veteran, was posted. I forward it for your information. I am not planning to start cross-posting messages in general; if you want to get involved in the IETF Fax discussions, please subscribe to that DL directly. Carl-Uno >Return-Path: >X-Sender: dcrocker@ng.netgate.net >Date: Tue, 12 Nov 1996 09:45:49 PST >To: Carl-Uno Manros >From: Dave Crocker >Subject: Re: PWG IPP charter >Cc: Raymond Lutz , ietf-fax@imc.org > >At 5:02 PM -0800 11/11/96, Carl-Uno Manros wrote: >>I am interested in finding out what you and others in the IETF Fax group >>think are the potentially overlapping areas between the two projects. > > my own opinion is that there is very substantial overlap... eventually. > > but very little overlap now, especially for the fax wg's initial >effort. > > Content formats will probably have no overlap initially. > > Transport/application protocol will have no overlap with fax store >and forward. > > Things will get a bit more interesting when the fax group starts to >consider interactive or real-time exchange. Even then, as Larry notes, >there are likely to be important differences. > >d/ > >-------------------- >Dave Crocker +1 408 246 8253 >Brandenburg Consulting fax: +1 408 249 6205 >675 Spruce Dr. dcrocker@brandenburg.com >Sunnyvale CA 94086 USA http://www.brandenburg.com > >Internet Mail Consortium http://www.imc.org, info@imc.org > Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 12 14:52:34 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11344 for ipp-outgoing; Tue, 12 Nov 1996 14:51:15 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 12 Nov 1996 12:51:06 -0700 From: Scott Isaacson To: ipp@pwg.org, pwg@pwg.org Subject: IPP FYI: Novell announcing free LDAP server Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I just saw this press release and wanted to post it to the IPP as yet another data point in the discussion about SVRLOC and LDAP and directory lookup. Scott PS: Keith Carter pointed out that the URL for the SVRLOC I-D is ftp://ietf.org/internet-drafts/draft-ietf-svrloc-protocol-14.txt Novell Removes the Barriers for Widespread Adoption of Directory Services for Networks Novell Offers Feature Rich LDAP Directory Server Free of Charge OREM, Utah C November 12, 1996 C Novell Inc. today announced an aggressive distribution strategy for Novell Directory Services (NDS) to accelerate its adoption by the industry's leading operating system vendors, creating a common directory service across heterogenous environments. Starting immediately, operating system developers can obtain a royalty-free source code and distribution license for NDS. Novell also disclosed its plans to offer a royalty-free binary distribution license for NDS on NT. As a cross-platform directory service, NDS provides a single point of access and management, increasing user productivity, reducing network administration costs and easing application development. In parallel with the new distribution strategy, Novell and its partners are creating new businesses through the licensing of replication, file, print, certificates and other directory-based products as add-ons to NDS. ANDS is years ahead of other directories in terms of technology and market share,@ said Tom Arthur, vice president and general manager of Novell's Internet Infrastructure Division. ANovell understands that the value of a network directory depends on the extent of its adoption. While other vendors are hoping to make a business of selling directories as servers or embedding them in proprietary operating systems, Novell is taking a different approach and seeding the market with NDS for directory-based applications and services.@ Novell is committed to integrating NDS into all major server platforms. The company has taken the first step by allowing the NDS source code to be licensed by industry-leading operating system providers, royalty-free. The company will also distribute a single server binary version of NDS on NT over the Internet and through agreements with independent software vendors (ISVs) and independent hardware vendors (IHVs). Partnerships with major ISVs and IHVs will be announced over the next several months. Customer Benefits Novell's platform-independent directory strategy will significantly increase user productivity by making it easier to find information on the network, regardless of where the information resides (corporate networks, intranets and the Internet). The directory will also help administrators to decrease network administration costs by reducing the time and complexity of managing disparate corporate networks. AAs one of the world's largest network integrators we have been providing NDS solutions in the NetWare environment for many years,@ said Stan Ratcliffe, vice president of EDS' Client/Server Group. AWe are very encouraged to see that NDS is becoming widely available on Unix and NT, thus providing simpler access, administration and development for heterogeneous networking systems.@ AThe availability of NDS on multiple operating systems gives us an opportunity that we've never had before to merge disparate platforms in our company under a single directory service,@ said Lee Roth, LAN Systems group leader, Southwest Airlines. NDS is an Open Directory By basing NDS on X.500 naming, Novell anticipated the industry's adoption of industry standards thus allowing NDS to be one of the first directories to offer LDAP support. To further its commitment to open standards, Novell plans to open NDS access APIs to Internet/intranet standards and ruling committees. The API documentation for NDS, including all of the directory service APIs for both client and service facilities are openly available on Novell's Web site at Developer Benefits Developers will finally be able to exploit new market opportunities by creating networked applications that leverage the performance benefits of distributed computing. NDS enables networked applications to share objects, such as Java applets, across networks, including intranets and the Internet. Novell's plans to openly distribute NDS, and its commitment to LDAP and X.500, offer a compelling, open environment for developing directory-enabled applications. Novell is also offering developers the opportunity to bundle NDS with their applications. This will provide the administration and security features they require, thus reducing the time and expense to develop and implement user account databases. With its directory services strategy, Novell provides a common directory infrastructure for developers to incorporate LDAP-compliant directory services into their networked applications and solutions, paving the way for developers to designate NDS as the LDAP directory of choice. Novell is (NASDAQ:NOVL) is the world's leading network software provider. Novell software provides the infrastructure for a networked world, enabling customers to connect with other people and the information they need, anytime and anyplace. Novell partners with other technology and market leaders to help customers make networks a part of their everyday lives. ### Novell is a registered trademark. Novell Directory Services, NDS are trademarks of Novell, Inc. All other registered trademarks are the property of their respective holders. Press Contact: Pattie Adams, Novell, Inc. Lori Hafen, Cunningham Communication, Inc. (408) 577-6056 (408) 764-0787 Internet: padams@novell.com Internet: lori@ccipr.com From ipp-archive Tue Nov 12 15:02:34 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA11787 for ipp-outgoing; Tue, 12 Nov 1996 14:59:47 -0500 (EST) Message-Id: Date: Tue, 12 Nov 96 14:57 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: Re: IPP PING for IETF BOF Meeting on December 12 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > Please send an indication to the DL to confirm your attendance. I plan to attend the BOF. However, does one have to register for the IETF plenary to attend a BOF? (I am not registered per se.) ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Tue Nov 12 16:07:34 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA11981 for ipp-outgoing; Tue, 12 Nov 1996 16:07:30 -0500 (EST) Message-Id: <2.2.32.19961112210555.009403e8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 13:05:55 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP Revised Charter Text Cc: ietf-fax@imc.org, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, xerox-ldpa@cp10.es.xerox.com Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi, here follows the revised PWG Charter text, rewritten by Scott Isaacson from Novell in a form that is more understandandable to anybody who was not present in the New Orleans PWG meeting. We will keep on polishing the text in our weekly phone conferences until everybody is happy. I am cross posting this also to the IETF Fax group to clear up any possible misunderstandings caused by our previous, rather unfinished, version. Carl-Uno ---- PWG Charter 4.0 11/12/96 Internet Printing Project (ipp) Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: Mailing lists: General Discussion: ipp@pwg.org To Subscribe: majordomo@pwg.org in body: subscribe ipp Archive: ftp://ftp.pwg.org/pub/pwg/ipp Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources such as printers and share documents and then printing using those resources. This working group will define a new application level distributed printing protocol as well as naming and service registration mechanisms. The protocol can be used in a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). Guiding principles for the working group include: - platform independence, - leverage existing technology, - support all types of output devices (not just printers), - keep it simple enough to embed in network attached printers, - hide printing complexity and implementation details, and - support all existing page description languages (including HTML). There are several roles in which humans act with respect to a given printer. These roles include: User, Operator, and Administrator. For example, Users submit jobs and then manage their own jobs. Operators monitor printer status and control and manage all jobs at the printer. Administrators create the printer instances and control the authorization of other Users and Operators. The working group will generally limit its scope to include only User functionality, however, there may be a need to define some basic Operator functionality as well. Users want to find and locate printers to which they are authorized to print. They want to search for printers using a standard Web browser. They search for printers based on name, geographic location, and other device related capabilities and attributes. Users also need a way to limit the scope or context of their searches. This includes support for searching for print devices both inside and outside their organizational fire walls. NOTE: Throughout this document, the term browser specifically means an Internet Web Browser (HTML, HTTP, Netscape, Internet Explorer, Mosaic, etc.). The term does not include MIB browsers or other browsers specific to a proprietary product or technology. Once users find printers, they want to be able to 'install' the printer into the native, desktop operating system on which they are running. This installation process includes installing any device specific components that are needed (e.g., the correct printer driver). This allows printing from any application (e.g., spreadsheet, word processor, browser, etc.). Users also want to print by reference. This means that instead of submitting a print job that contains the entire document contents, a job can be submitted that contains only a reference to some existing document or set of documents. This reference is resolved prior to actually printing the document(s). Users want to set certain print job parameters at the time the job is submitted (e.g., number of copies, priority, job defaults, etc.). The underlying protocol must support job-to-printer capability matching. This involves knowing both printer attributes and job attributes as well as having the ability to reason about relationships between the values of these attributes. This is useful for rejecting print jobs that can not be printed (at submission time rather than at print time) as well as automatically locating a printer that is capable of printing a certain job. Once a print job has been submitted and is being processed, users need to be able to cancel their own print jobs. Users want to verify both the characteristics and status of both jobs and print devices by using a browser. When checking the status of a device, users want to know how many jobs are being processed by the device as well as how many jobs are 'in front of' a given job. Users also want to be able either to turn on or turn off job and device status reporting. The working group will define a set of printing related events and also specify the notification methods that can be used. The working group shall leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. The working group must define solutions that do not preclude the notion of multi-tiered configurations consisting of both logical and physical printers. Also, the new job submission protocol must not preclude submitting jobs to any type of output device (e.g., fax, printer, gateway). Also, the working group shall define extensibility paths so that similar extensions will interoperate and proprietary, dissimilar extensions will never conflict. The working group will not undertake defining a standard API set for Internet printing, but will support redirection from current print subsystems and interfaces as well as support direct programmatic implementations by vertical applications. The working group shall encourage and solicit the input and participation from all printing related individuals and companies. For example, the working group will not only encourage participation by experts from printer vendors, but representatives from browsers, client desktop operating systems, network operating systems, Internet service providers, Page Description Languages (PDLs), and commercial service bureaus. Also, the working group shall coordinate its activities with other printing-related standards bodies. The working group will not re-invent nor concern itself with the following issues: - how operating systems 'temporarily' install printers - command line tools and interfaces - input devices such as scanners and fax-in - nested HTML documents This working group may define work that will replace RFC 1179 'Line Printer Daemon Protocol' LPR/LPD was designed a long time ago with line printers in mind. It does not fit with current page oriented printing technologies. Most printer vendors have made their own proprietary extensions which are mutually incompatible. The specifications out of this working group must enhance RFC 1179 in the following ways: - Useful yet practical mechanisms for interoperability and extensibility - Support for the more complex, multiple content, multiple document, page oriented languages and printers of today - Support for the new Internet and Web technologies of today This effort will be developed and prototyped within a 6 month period since there has been considerable prior work done in this area. This prior body of work includes: - ISO/IEC 10175 Document Printing Application (DPA) parts 1 and 3. - POSIX System Administration - Part 4 (POSIX 1378.4) - X/Open, 'A Printing System Interoperability Specification(PSIS)' - RFC 1759, Printer MIB Goals and Milestones: Weekly teleconference - Wednesdays, starting November 13, 1997 Mailing list - up and working November 22, 1996 - issue Internet-Draft document to IETF December 12, 1996 - attend BOF in IETF meeting in San Jose End December, 1996 or earlier - have IETF WG created April 1997 meeting of IETF - final polishing of specification April 1997 meeting of IETF - demo of prototype(s) May 1997 - First RFC(s) ready for publishing (further milestones between January - April 1997 to be added) Internet-Drafts: No Current Internet-Drafts. Request For Comments: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1759 PS Mar 95 Printer MIB Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 12 19:07:36 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA13128 for ipp-outgoing; Tue, 12 Nov 1996 19:04:27 -0500 (EST) Message-Id: <2.2.32.19961113000334.008f27cc@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 16:03:34 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP Agenda for Teleconference - Wednesday November 13 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 15:39 12.11.96 PST, you wrote: > >Carl, I have two things to add to the agenda ... > I have given a quick response below, the rest I will be happy to add to the agenda. Carl-Uno -- >1) process for "signing up" for the IETF BOF (See Jay Martin's question. Do we >have to sign up, pay registration fee to attend just the BOF? > The details for this is on: http://www.ietf.org/meetings/SanJose.html This site seems to be very busy so you you may have to try several times before you succeed. My understanding is that everybody who attends is supposed to register and pay the meeting fee, even if you just come in for the BOF. Although the IETF prefers to have people register in advance (to plan for meeting rooms etc.), you can in effect just walk in from the street without pre-registration. If you plan to do that, reserv a bit of extra time to do this before the BOF. I am not sure what the meeting fee is, last time I attended it was $100. >2) I asked Scott Issacson to come back with a Novell position on using http >instead of rpc at this first call. > Scott, are you listening? >---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/12/96 04:35 >PM --------------------------- > Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 12 19:52:36 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA13343 for ipp-outgoing; Tue, 12 Nov 1996 19:49:28 -0500 (EST) To: cmanros@cp10.es.xerox.com CC: ipp@pwg.org In-reply-to: <2.2.32.19961113000334.008f27cc@garfield> (message from Carl-Uno Manros on Tue, 12 Nov 1996 16:03:34 PST) Subject: Re: IPP Agenda for Teleconference - Wednesday November 13 From: Larry Masinter Message-Id: <96Nov12.165007pdt."130"@palimpsest.parc.xerox.com> Date: Tue, 12 Nov 1996 15:50:07 PST Sender: ipp-owner@pwg.org Precedence: first-class Status: RO For information about IETF, http://www.ietf.org provides a lot of information. It's useful to check out the "instructions" and "The Tao of IETF" links on that page. The registration fee is $270. Larry From ipp-archive Tue Nov 12 21:07:37 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA13589 for ipp-outgoing; Tue, 12 Nov 1996 21:04:55 -0500 (EST) Message-Id: <3.0.32.19961112175024.0098f0c4@crash.cts.com> X-Sender: raylutz@crash.cts.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 12 Nov 1996 18:02:31 -0800 To: Carl-Uno Manros From: Raymond Lutz Subject: Re: IPP Agenda for Teleconference - Wednesday November 13 Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi Carl-Uno: On the teleconference: I think it would be appropriate to discuss potention overlap of the ipp charter with the ietf-fax charter. Both charters are open for discussion at this time. I would prefer to see a joint effort in a merge-purge operation of these things, and perhaps we can see some important issues that will benefit both projects and decide on who will handle these. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair MFPA: 1-800-603-MFPA ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ From ipp-archive Wed Nov 13 02:50:06 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA14093 for ipp-outgoing; Wed, 13 Nov 1996 02:45:18 -0500 (EST) Date: Tue, 12 Nov 1996 23:45:33 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611130745.XAA17617@woden.eng.sun.com> To: ipp@pwg.org, pwg@pwg.org Subject: IPP document for ipp phone call on Wednesday 11/13 X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have downloaded the latest document for the IPP work to the pwg server. It is in the directory /pub/pwg/ipp/new/. The documents are in MS Word, PostScript and PDF. The MS Word and PostScript documents are also zipped. This document started with the ldpa8.doc file in the ldpa directory. All changes to it are marked with revision marks. Bob Herriot From ipp-archive Wed Nov 13 03:02:40 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA14552 for ipp-outgoing; Wed, 13 Nov 1996 03:01:18 -0500 (EST) Message-Id: <9611130758.AA20004@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 23:55:19 PST To: ipp@pwg.org From: Tom Hastings Subject: For IPP Wed 13-Nov telecon: proposal for objects, operations, and attributes for IPP Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Roger deBry (IBM), Bob Herriot (Sun), and I (Tom Hastings, Xerox) completed our homework assignment on working on the subset of ISO DPA operations, objects, and attributes for IPP. We've taken the LDPA8.DOC that Scott Isaacson contributed to the PWG meeting and edited it with revision marks turned on so that you can see the changes. We've not added much about HTTP, except that that is the current thinking. I recommend that we all copy the .pdf file, rather than the .doc file, so that we will all have the same line numbers. For a telecon, it is very helpful if we all have the same line numbers. (Depending on whether you are using WORD 6.0 or WORD 7.0 and the fonts and drivers you use, the line numbers can get substantially off, if you print from WORD). The files have been copied to: ftp://ftp.pwg.org/pub/pwg/ipp/new/ -rw-r--r-- 1 pwg pwg 401408 Nov 13 06:27 ipp.doc -rw-r--r-- 1 pwg pwg 91388 Nov 13 06:27 ipp.doc.zip -rw-r--r-- 1 pwg pwg 350663 Nov 13 07:20 ipp.pdf Tom Hastings At 17:40 11/11/96 PST, Carl-Uno Manros wrote: >The IPP project decided to hold telephone conferences weekly (almost) on >Wednesdays, 1 - 3 pm PST, 4 - 6 EST. The first one is coming up this week. > >To connect to the conference you dial: > > (423) 544 0905, when prompted enter access code: 114698 > >My suggestion for Agenda topics this Wednesday: > >- Review IPP Minutes from New Orleans >- Review IPP Charter from New Orleans > (expect an improved version by Wednesday morning) >- Check on progress of home work assignments: > - Subset of DPA attributes to be used as job and printer attributes > - Schemas for Directory information about printing > - Service Location protocol or LDAP mappings > (unfortunately, the minutes do not reflect who volonteered for which home >work assignment, but let your concience tell you. Please distribute any >results to the DL in advance) >- Discuss Agenda for the IETF BOF - Needs to go out after this phone conference > (see earlier agenda proposal that I sent to IETF) >- Discuss TOC and level of detail for the Internet Draft document > >If you think that I have left anything important out, drop a message to the >DL ASAP. > >Speak to you soon, > >Carl-Uno > > >Carl-Uno Manros >Xerox Corporation >701 S. Aviation Blvd. >M/S: ESAE-231 >El Segundo, CA 90245, USA >E-mail: manros@cp10.es.xerox.com > > > From ipp-archive Wed Nov 13 11:47:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA15406 for ipp-outgoing; Wed, 13 Nov 1996 11:43:21 -0500 (EST) Message-Id: Date: Wed, 13 Nov 96 11:40 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: IPP Cost for attending just the IETF BOF on Internet Printing Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Looks like you have to pay the full registration fee, even if this BOF is the only event you attend. Sigh. ...jay > From jkm Tue Nov 12 15:28:44 1996 > Date: Tue, 12 Nov 96 15:28 EST > From: jkm (JK Martin) > To: ietf-rsvp@ietf.org > Subject: Question regarding registration cost for BOF-only attendance > Cc: jds, jkm > > Hello, > > Due to scheduling constraints I will only be able to attend a single BOF, > the one having to do with "Internet Printing". > > Can you tell me whether I will be able to attend this single BOF at no > charge, or what the fee will be? (I am hoping that I don't have to pay > for the entire week for just this one BOF!) > > 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 03015-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > ------------------------------------------------------------------------------ > From mac-31!ietf.org!juliek Tue Nov 12 15:54:45 1996 > Mime-Version: 1.0 > Date: Tue, 12 Nov 1996 15:56:49 -0600 > To: JK Martin > From: Julie Kirchhoff > Subject: Re: Question regarding registration cost for BOF-only attendance > > Hi! Sorry, no special discounts - we only have the one fee. > Hope to see you anyway! > Julie > > > Julie A. Kirchhoff > IETF Meeting Registrar > Corporation for National Research Initiatives > 1895 Preston White Drive, Suite 100 > Reston, VA 20191-5434 > TEL: 703/620-8990 FAX: 703/758-5913 > E-MAIL: juliek@cnri.reston.va.us From ipp-archive Wed Nov 13 12:12:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15605 for ipp-outgoing; Wed, 13 Nov 1996 12:10:03 -0500 (EST) Message-Id: <2.2.32.19961113170754.00929c44@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Nov 1996 09:07:54 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP Agenda for Teleconference - Wednesday November 13 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 18:02 12.11.96 PST, you wrote: >Hi Carl-Uno: > >On the teleconference: > >I think it would be appropriate to discuss potention overlap of the ipp >charter with the ietf-fax charter. Both charters are open for discussion at >this time. I would prefer to see a joint effort in a merge-purge operation >of these things, and perhaps we can see some important issues that will >benefit both projects and decide on who will handle these. > >-Raymond > > Ray, time permitting, we can start discussing that subject too, but I would like to have some written input from you that we can discuss around. Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 13 12:52:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15828 for ipp-outgoing; Wed, 13 Nov 1996 12:50:38 -0500 (EST) Mime-Version: 1.0 Date: Wed, 13 Nov 1996 12:52:57 -0500 Message-Id: <00008548.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP Agenda for Teleconference - Wednesday November 13 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: first-class Status: RO I suggest that the discussion of IETF-FAX/IPP overlap be limited to the observation, reflected by Dave Crocker, that there appears to be no overlap at this time, but that we will continue to be aware the each other's efforts via the public mail lists. Although I share Raymond's apprehension with regard to the potential overlap, the paths taken by the two groups seem to have avoided this. IPP is concerned with the more elemental process of printing, specifically of discovery, delivery and denouement (ok..its a stretch). IETF-FAX is concerned with ... FAX, which is a more complex process and for which no reasonable definition has emerged. The service models in the IETF_FAX charter are: A: Messaging, apparently email delivery of encapsulated 'traditional' fax: no overlap B: Session-based, for observed delivery, with or without capabilities negotiation, and for which some have suggested LDPA may be appropriate. But there is still the notion of encapsulating a 'traditional' fax transmission C. Real-time, for telephone replacement and transparent to existing fax machines, to which there certainly seems no overlap. The printing/internet and the FAX/Email groups each have enough of a task in resolving the disparate cultures within themselves without attempting an all-inclusive approach from the start. Bill Wagner, DPI ______________________________ Reply Separator _________________________________ Subject: Re: IPP Agenda for Teleconference - Wednesday November 13 Author: Carl-Uno Manros at Internet Date: 11/13/96 9:07 AM At 18:02 12.11.96 PST, you wrote: >Hi Carl-Uno: > >On the teleconference: > >I think it would be appropriate to discuss potention overlap of the ipp >charter with the ietf-fax charter. Both charters are open for discussion at >this time. I would prefer to see a joint effort in a merge-purge operation >of these things, and perhaps we can see some important issues that will >benefit both projects and decide on who will handle these. > >-Raymond > > Ray, time permitting, we can start discussing that subject too, but I would like to have some written input from you that we can discuss around. Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 13 13:38:37 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16078 for ipp-outgoing; Wed, 13 Nov 1996 13:36:32 -0500 (EST) Message-Id: <2.2.32.19961113175420.0095af94@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Nov 1996 09:54:20 PST To: Harald.T.Alvestrand@uninett.no, ipp@pwg.org From: Carl-Uno Manros Subject: IPP Re: Revised Charter Text Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Harald, you are absolutely right. This charter document was written for the PWG rather than the IETF at this stage, and is probably a bit too chatty for a charter document in general. I realize that we need a much meaner and leaner document before sending it to the IETF. Your comments will be taken as strong advice on how to produce that. Thanks, Carl-Uno At 04:34 13.11.96 PST, you wrote: >Carl-Uno, >(all lists removed for my peace of mind) >I think you have an editing job on your hands. > >First off, I'm not going to accept a 4-page charter. Period. >If you can't express what you want to do in an understandable >form in 1 page, the group doesn't have focus. >I'll allow you another page for "administrativia", but go above >160 lines, and I'm not going to approve it. > >You're free to issue an internet-draft with background material >and reference that in the charter if you want a place to put more text. > >Second, wrt your working style: I can give you two choices on the >teleconferences: >- Either they're WG meetings, and they're open to *everyone* who > wants to be in on them >- Or they're design team meetings, which may include anyone you want, > but are NOT mentioned explicitly in the charter. > >Third, scope of work: > >At the moment, the draft charter (as I read it) defines: >- A service location protocol using a Web browser >- A printer usage protocol (still unspecified) >- A printer management protocol, partly using a Web browser > >Service location touches the SRVLOC WG, which has a long and confusing >history. One of its current work items is leveraging its protocol to >support finding printers. Coordinating with them is the least I can ask. > >Using a Web browser to look at and control things touches the awful mess >called Web-based management. I'm not sure I would want you to get into >that very deeply; the right thing to do might to write up something >mind-bogglingly simple using HTML and HTML forms as a "suggested >practice", and then wait for the HTTP management stuff to jell before >revisiting the battlefield. >(BTW, I've turned down the request for a BOF on HTTP-based management) > >Fourth, milestone list: > >- Nov 12, Dec 12 milestones are OK. We generally give just the month, > not the date on milestones. >- Don't show "WG created" on the milestone list that you submit to us. >- Show "demo of prototypes" as "at least 2 implemented prototypes". > We don't encourage demos at the IETF; if you want to do it then, host it > offsite. Fear of getting swamped, I think... >- May 1997 should read "Submit document to the IESG for Proposed Standard" > >I think you have a good chance of getting a good charter out of this >- just remove most of the explanations! > > Harald A Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 13 14:12:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16335 for ipp-outgoing; Wed, 13 Nov 1996 14:09:18 -0500 (EST) Message-Id: <3.0.32.19961113110621.009f5ee0@crash.cts.com> X-Sender: raylutz@crash.cts.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Wed, 13 Nov 1996 11:07:29 -0800 To: ipp@pwg.org, ietf-fax@imc.org From: Raymond Lutz Subject: IPP Headlines: Fax and Printing get "mixed up" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO [Note: I am copying both ipp and ietf-fax mailing lists since this message affects both groups.] As a representative for MFPA, we are interested in both Facsimile and Printing. It is definitely important to these manufacturers to have a common methodology so that a device need not have disjointed approached for the printing of fax images or the printing of printer files. I am reflecting on a curious situation: First, let's review "history": 1) PRINTING: Printing has customarily been a "batch" oriented affair, frequently with one or more spooler queues between the act of submission and the printer. There is no "negotiation" with the printer because the driver is matched to the printer and knows very well the printer can perform. The data content standards for printing are nearly all proprietary, with all standards-based data-content formats never forming any true backing in the industry (such as IOS-8613 ODA). The "protocol" is minimal, just copy data to the device. (True, some recent devices have two-way protocols). 2) FACSIMILE: Facsimile is a combination of a negotiation protocol and a collection of standard data formats. The protocol is required to optimize the use of the scanner and printer devices in a dial-up situation. The protocol provides for negotiation of capabilities of the marking device so that the transmitter may scan the data to a resolution no less than that actually required by the marking engine. (True, some recent fax-server and computer-fax software doesn't really support much in the way of negotiating all formats, and run in more of a queued "printer model" mode. Now: 1) FACSIMILE: the ietf-fax group is advancing the idea that "internet facsimile" will be the simple transport of compressed images, with little or no capabilities negotiation. Luckily, we have a "small" set of capabilities that may need to be negotiated, and bandwidth issues are not an issue with "free" bandwidth of the internet, so compressed images may as well be sent at very high resolution, regardless of the capabilities of the printer. This group is willing to ignore the scanning operation, which is a noted deficiency in their scope compared with customary facsimile. 2) PRINTING: customary printer files will fit into a MIME attachment very nicely, but due to the large amount of variation in the type of printer file formats, fonts, etc. internet printing now more than ever requires the sort of negotiation that was historically used for facsimile. The situation of having a driver matched with the printer no longer holds. IS THIS "MIX-UP" and "REVERSAL OF ROLES" A PROBLEM? Not really. But I would hope that these groups will acknowledge that their work does overlap in the area of capabilities negotiation with the remote device. (I am a bit worried that attacking the PRINTING problem using customary file formats for print jobs will be difficult to standardize due to the complexity of these file formats. This would result in ipp protocols only useful for intranet applications instead of the more general internet issues.) If MIME is used to transmit print jobs (whether they be G3fax, TIFF/F, PCL, PostScript, SPIFF, LDPA "spooler" format, HTML, or whatever) from one site to another (and this is indeed a handy facility to have) then if the destination cannot handle the job, the return-receipt methodology can be used to indicate the capabilities of the remote device. Please, let's not come up with different methods for this common problem. The comments that "they have enough internal problems in their group" is a joke. These are not different groups, they are composed of many of the same companies that will need to implement BOTH schemes. PROPOSAL: I propose that the protocol issues be handled by one of the following: - Jointly. - By a separate group with which both groups would liaison. maybe the return-receipt group is that group. Regards, -Raymond Lutz /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair MFPA: 1-800-603-MFPA ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ From ipp-archive Wed Nov 13 14:17:47 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16574 for ipp-outgoing; Wed, 13 Nov 1996 14:13:18 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 13 Nov 1996 12:12:53 -0700 From: Scott Isaacson To: ipp@pwg.org Subject: IPP Action Items Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I did make a list of action items and I have posted them in PDF on: ftp://ftp.pwg.org/pug/pwg/ipp/actions/961113.pdf One of our action items ought to be how to structure this directory and how to name documents. There was some e-mail on this in the PWG a few months ago, but I have lost track. Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Wed Nov 13 14:17:48 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA16513 for ipp-outgoing; Wed, 13 Nov 1996 14:12:51 -0500 (EST) Message-Id: <3.0.32.19961113102720.009963e4@crash.cts.com> X-Sender: raylutz@crash.cts.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Wed, 13 Nov 1996 11:07:26 -0800 To: ipp@pwg.org From: Raymond Lutz Subject: IPP ietf-fax charter Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_847940846==_" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO --=====================_847940846==_ Content-Type: text/plain; charset="us-ascii" Since the ipp group may not be aware of the content of the charter of the ietf-fax group, I am submitting it to this list. I have some comments that I will submit separately. -Raymond --=====================_847940846==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable INTERNET FAX (FAX) CHARTER CHAIR(S): APPLICATIONS AREA DIRECTOR(S) Keith Moore Harald.T.Alvestrand@uninett.no AREA ADVISOR MAILING LISTS: General Discussion: ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-fax/ DESCRIPTION OF WORKING GROUP: Facsimile (fax) serves as a reliable, inexpensive global communications service. As the Internet becomes pervasive, integrating fax and Internet services is appealing in terms of cost- savings and opportunities for functional enhancements. This working group will pursue an initial round of review and specification for enabling standardized fax over the Internet. In the interest of making progress quickly, an email-based service will be the first transport mechanism pursued, since it requires the least additional technical effort. Facsimile/Internet integration can be considered in terms of three user service models, in order of increasing technical difficulty: =85 Messaging, e.g., email & high latency =85 Session-based, for observed delivery, with or= without capabilities negotiation =85 Real-time, for telephone replacement and transparent to existing fax machines For interconnecting fax services over the dialup telephone network and carriage of fax data over the Internet, two types of translations devices are required: =85 Internet/Dialup Fax gateway, moving data from the Internet to classic or Internet-aware dialup fax services =85 Dialup/Internet Fax gateway, moving data from classic or Internet- aware dialup fax services to the Internet This working group shall include consideration of requirements for these gateways, but will defer specifying their details. The Fax working group will focus on an initial set of activities to create a core fax-related service over the Internet, using existing protocols and specifications where possible. Its activities will include development of standardized terminology, standardized data representation, and standardized data transport methods, attending to addressing and reliability concerns. Common terminology will ensure a shared framework for participants from the Internet and the facsimile worlds. The second task will review existing facsimile-related Internet data specifications and accept, modify, replace or augment them, with particular attention to their encapsulation, such as via MIME. The third task will provide for carriage of facsimile data via Internet mail The fourth task will detail the operational constraints for achieving session-oriented use of messaging, tailored for timely delivery with the sender waiting for delivery confirmation. The dominant use of fax today is during a real-time connection over the dialup telephone network; hence an Internet-based direct replacement service would save significant long-distance telephone charges. However it is believed that this service is the most difficult task to produce over the Internet, technically, whereas an email-based service is likely to be the simplest. The working group shall coordinate its activities with other facsimile-related standards bodies. GOALS AND MILESTONES: Feb, 97 Submit terminology document and new or modified data specifications onto standards track Mar, 97 Submit email specification onto standards track Jul, 97 Submit interactive-time fax-over-Internet specification onto standards track --=====================_847940846==_ Content-Type: text/plain; charset="us-ascii" /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair MFPA: 1-800-603-MFPA ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ --=====================_847940846==_-- From ipp-archive Wed Nov 13 22:42:52 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA18154 for ipp-outgoing; Wed, 13 Nov 1996 22:41:09 -0500 (EST) Message-Id: <2.2.32.19961114024348.009d5830@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Nov 1996 18:43:48 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Meeting Info about IETF in San Jose Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I may not be the only one that has had difficulty to download some of the IETF documents from their server. I managed to get the following meeting info by signing on in the middle of the night: ---- > ****37th IETF: December 9-13, 1996/San Jose, CA**** > > >PLEASE NOTE THE FOLLOWING: > >1. NEWCOMER's ORIENTATION: On Sunday, December 8th at 1530 we will be > holding an orientation session for Newcomers (Room: Crystal Room) > ALL FIRST TIME ATTENDEES ARE ENCOURAGED TO READ RFC 1718 BEFORE > ATTENDING THE MEETING. Entitled "The Tao of IETF: A Guide for New > Attendees of the Internet Engineering Task Force", this RFC is available > by anonymous FTP, although an updated version is available via the > WEB. > >2. PRE-REGISTRATION and a RECEPTION will be held on Sunday, December 8th > from 1700 - 1900 (Room: Regency I & II). > >3. A Working Group Chairs Workshop will be held during lunch on Monday, > December 9th at 1130. Anyone interested in learning about the role of > the working group chair is welcome to attend. Location: TBD. > >4. The Agenda below is a DRAFT and therefore subject to frequent changes. > We do not advise you use it to determine travel arrangements. > >-------- >FYI..... > >A reminder that the quality of these meetings (and in particular the >Working Group technical *working* sessions) is dependent upon the >informed, constructive participation of the individual attendees. Please >come prepared. > >Information on the current status and progress of the individual >Working Groups can be obtained in several ways: > >1. Working Group objectives and notes from previous sessions are > available online (send to ietf-info@ietf.org for retrieval > instructions). > >2. Working Group objectives and notes from previous meetings are > also reproduced in the hardcopy Proceedings (to order, send to > proceedings@ietf.org). > >3. Agendas and reading lists for Working Group meetings will also be > posted to the respective Working Group mailing lists. And when > submitted to the Secretariat will be made available via the web. > >IF YOU HAVE QUESTIONS REGARDING THE SCHEDULING OF A PARTICULAR WORKING >GROUP, PLEASE CONTACT THE CHAIR OF THAT GROUP DIRECTLY. A LISTING OF >WORKING GROUP MAILING LISTS IS AVAILABLE VIA ANONYMOUS FTP, CD IETF, >GET "1wg-summary.txt". > >LOOKING AHEAD.... > >Information on future IETF meetings is available from the FTP Directories. >Look under filename "0mtg-sites.txt". > > ------ > DRAFT Agenda of the Thirty-Seventh IETF > (December 9-13, 1996) > As of 10/28/96 > >MONDAY, December 9, 1996 > >0800-0900 IETF Registration and Continental Breakfast >0900-0930 Introductions >0930-1130 Morning Sessions > > APP http HyperText Transfer Protocol WG > INT ipcdn IP Over Cable Data Network WG > MGT rmonmib Remote Network Monitoring WG > OPS rps Routing Policy System WG > >Break >1300-1500 Afternoon Sessions I > > APP drums Detailed Revision/Update of Message Standards WG > INT ipngwg IPNG WG > MGT trunkmib DS1/DS3 MIB > RTG qosr QoS Routing BOF > SEC pkix Public-Key Infrastructure (X.509) WG > USV uswg User Services > >1500-1530 Break (Refreshments provided) >1530-1730 Afternoon Sessions II > > APP ediint Electronic Data Interchange-Internet Integration WG > INT ion Internetworking Over NBMA WG > OPS mboned MBONE Deployment WG > SEC tls Transport Layer Security WG > USV isn Internet School Networking WG > >1930-2200 Evening Sessions > > APP mhtml MIME Encapsulation of Aggregate HTML Documents WG > INT ion Internetworking Over NBMA WG > INT ipngwg IPNG WG > USV isnII Internet School Networking BOF (Educators) > >TUESDAY, December 10, 1996 > >0830-0900 Continental Breakfast >0900-1130 Morning Sessions > > APP http HyperText Transfer Protocol WG > INT ipcdn IP over Cable Data Network WG > MGT atommib AToM MIB WG > OPS ippm IP Performance Metrics > RTG mobileip IP Routing for Wireless/Mobile Hosts WG > SEC cat Common Authentication Technology WG > >Break >1300-1500 Afternoon Sessions I > > APP calsch Calendaring and Scheduling BOF > INT pppext Point-to-Point Protocol Extensions WG > MGT rmonmib Remote Network Monitoring WG > OPS mboned MBONE Deployment WG > SEC pkix Public-Key Infrastructure (X.509) WG > >1500-1530 Break (Refreshments provided) >1530-1730 Afternoon Sessions II > > APP ftpext Extensions to FTP WG > INT ion Internetworking Over NBMA WG > OPS 6bone IPv6 Backbone BOF > RTG rip Routing Information Protocol WG > SEC ipsec IP Security Protocol WG > >WEDNESDAY, December 11, 1996 > >0830-0900 Continental Breakfast >0900-1130 Morning Sessions > > APP ids Integrated Directory Services > INT pktway PacketWay WG > MGT agentx SNMP Agent Extensibility WG > OPS rtfm Realtime Traffic Flow Measurement WG > RTG tagsw Tag Switching BOF > SEC dnssec Domain Name System Security WG > >Break >1300-1500 Afternoon Sessions I > > APP find Common Indexing Protocol WG > INT dhc Dynamic Host Configuration WG > MGT applmib Application MIB WG > OPS rps Routing Policy System WG > RTG ospf Open Shortest Path First IGP WG > SEC spki Simple Public Key Infrastructure BOF > >1500-1530 Break (Refreshments provided) >1530-1730 Afternoon Sessions II > > APP asid Access, Searching and Indexing of Directories WG > INT pppext Point-to-Point Protocol Extensions WG > MGT disman Distributed Management WG > RTG idmr Inter-Domain Multicast Routing WG > SEC cat Common Authentication Technology WG > USV run Responsible Use of the Network WG > >1930-2200 Evening Sessions > > APP acap Application Configuration Access Protocol BOF > GEN iab Internet Architecture Board Open Meeting > INT dhc Dynamic Host Configuration WG > MGT disman Distributed Management WG > OPS rwhois RWhois Operational Development WG > RTG mobileip IP Routing for Wireless/Mobile Hosts WG > >2230 Late Night Session > > PGP Key Signing Party > >THURSDAY, December 12, 1996 > >0830-0900 Continental Breakfast >0900-1130 Morning Sessions > > APP urn Uniform Resource Names WG > MGT atommib AToM MIB WG > OPS rtfm/ippm Realtime Traffic Flow Measurement/IP Performance > RTG idmr Inter-Domain Multicast Routing WG > SEC otp One Time Password Authentication WG > USV ssh Site Security Handbook WG > >Break >1300-1500 Afternoon Sessions I > > INT ipngwg IPNG WG > MGT applmib Application MIB WG > RTG idr Inter-Domain Routing WG > SEC saag Open Security Area Directorate Meeting BOF > USV harts Humanities and Arts WG > >1500-1530 Break (Refreshments provided) >1530-1700 Presentations > > o xDSL Aspects and Technologies > Kim Maxwell (chair of ADSL Forum) > > o NSF Routing Arbiter Project > Ramesh Govindan (USC/Information Sciences Institute) > Brian Renaud (Merit Network Inc.) > > o TCP Plotting Method > Tim Shepard (BBN) > > o Next Generation Internet Initiative > Tom Kahil > >1700-1900 Open Plenary and IESG > >FRIDAY, December 13, 1996 > >0830-0900 Continental Breakfast >0900-1130 Morning Sessions > > INT/SEC dnsind/dnssec DNS IXFR, Notification and Dynamic Update > GEN q&a Question & Answer for Next Generation Internet Initiative > MGT frnetmib Frame Relay Service MIB WG > OPS ngtrans New Generation Transition WG > >Key to Abbreviations > >APP Applications Harald Alvestrand/UNINET and > Keith Moore/UTK >GEN General Interest Fred Baker/Cisco Systems >INT Internet Frank Kastenholz/FTP Software and > Jeffrey Burgan/Bay Networks >MGT Network Management Deirdre Kostick/AT&T >OPS Operational Requirements Scott Bradner/Harvard and > Michael O'Dell/UUNET Technologies >RTG Routing Joel Halpern/Newbridge Networks >SEC Security Jeff Schiller/MIT >TSV Transport Allison Mankin/ISI and > Allyn Romanow/Sun Microsystems >USV User Services Joyce K. Reynolds/ISI ------ >37th INTERNET ENGINEERING TASK FORCE Mailing Date: >AT-A-GLANCE > >DATES: December 9-13, 1996 > >HOTEL/MEETING SITE: San Jose Fairmont Hotel > 170 South Market Street > San Jose, CA 95113-2395 > Phone: 1 (408) 998-1900 or 1 (800) 527-4727 > {fax: 1 (408) 280-6072} > CI 1600; CO 13:00 > 340 Rooms reserved until Friday, November 8, 1996. > US$122.00/single; US$132.00/double > (please add 10% tax). > Specify: IETF Group > >ADDITIONAL HOTELS: Holiday Inn (3 blocks from Fairmont Hotel) > 282 Almaden Boulevard > San Jose, CA 95113 > Phone: 1 (408) 998-0400 (Call hotel directly, ONLY) > Fax: 1 (408) 289-9081 > CI 1400; CO 1200 > 50 Rooms reserved for dates December 8 - 13, 1996 > US$129.00 single/double > (please add 10% tax) > CANCELLATION POLICY: any cancellations within 72 hours > from the date of arrival will be billed for one (1) > night room and tax. > Specify: IETF Group > > Hotel De Anza (6 blocks from Fairmont Hotel) > 233 W. Santa Clara Street > San Jose, CA 95113 > Phone: 1 (408) 286-1000 > Fax: 1 (408) 286-0500 > CI 1500; CO 1200 > 30 Room reserved for dates December 8 - 13, 1996 > US$135.00 single/double > (please add 10% tax) > Specify: IETF Group > > Hyatt (1/2 block from Fairmont Hotel) > 302 South Market Street > San Jose, CA 95113 > Phone: 1 (408) 295-2000 (Call hotel directly ONLY) > Fax: 1 (408) 295-3306 > CI 1500; CO 1200 > 20 Rooms reserved for dates December 8 - 13, 1996 > US$145.00 single/double > (please add 10% tax) > Specify: IETF Group > >NEWCOMER'S Sunday, December 8, 1996 >ORIENTATION: 15:30 - 16:30 > PLEASE NOTE THAT THE TIME IS ONE HOUR EARLIER THAN > PREVIOUS MEETINGS > San Jose Fairmont Hotel > Room: Crystal Room > >PRE-REGISTRATION: Sunday, December 8, 1996 > 17:00 - 19:00 (reception) > PLEASE NOTE THAT THE TIME IS ONE HOUR EARLIER THAN > PREVIOUS MEETINGS > San Jose Fairmont Hotel > Room: Regency I & II > >REGISTRATION: Monday, December 9, 1996 > and BREAKS 08:00 - 18:00 > Tuesday, December 10 - Thursday, December 12, 1996 > 08:30 - 18:00 > Friday, December 13, 1996 > 08:30 - 12:00 > San Jose Fairmont Hotel > Room: Market St. Foyer > >TERMINAL ROOM: Gold Room > >ATTENDANCE FEE: PAYMENT BY: Credit Card or Check > >AIRLINE: United Airlines (special rate roundtrip only) > 1 (800) 521-4041 Meeting ID: 566RE (IETF) > We regret that discounted fares are not > available for international flights > >AIRPORT: San Jose International > >PARKING: Current rate as of February 1, 1996 is $9.50 per day. > >SHUTTLE: TBD ------- > 37th IETF Meeting - San Jose, CA > December 9-13, 1996 > > >DIRECTIONS TO THE FAIRMONT HOTEL (SAN JOSE) > >The Fairmont Hotel >170 South Market Street >San Jose, CA 95113 >Phone: 408-998-1900 > > >FROM THE NORTH ON HIGHWAY 101 (SAN FRANCISCO) >============================================= > >Take Highway 101 south. Take the 87/Guadalupe Parkway exit. Continue >down Guadalupe three miles to the Park Avenue exit. Make a left on Park >and continue down two blocks. Park Avenue will end at Market Street. >Turn right and circle Plaza de Caesar Chavez Park. The hotel is located >at 170 South Market Street; the cross street is San Fernando. > > >FROM HIGHWAY 280/680 IN EITHER DIRECTION >======================================== > >Take the Guadalupe Parkway exit. Continue down Guadalupe one quarter of >a mile to the Santa Clara Street exit. Make a right on Santa Clara Street. >Go four lights to Market Street and make a right. Continue on Market two >blocks and circle Plaza de Caesar Chavez Park. The hotel is located at >170 South Market Street; the cross street is San Fernando. > > >FROM HIGHWAY 880/17 IN EITHER DIRECTION >======================================= > >Take the Coleman Avenue exit. Make a left on Coleman from either direction. >Continue on Coleman two miles where it will become Market Street. Continue >on Market eight blocks to San Fernando Street. Circle Plaza de Caesar >Chavez Park. The hotel is located at 170 South Market Street. > > >FROM THE SOUTH ON HIGHWAY 101 (LOS ANGELES) >=========================================== > >Take Highway 101 north to Highway 280 north. The third exit will be the >87/Guadalupe Parkway exit. Continue down Guadalupe one quarter of a mile >to the Santa Clara Street exit. Make a right on Market Street and go two >blocks to the hotel, which will be on your left. Circle Plaza de Caesar >Chavez Park. The Fairmont is located at 170 South Market Street; the cross >street is San Fernando. >Content-Type: TEXT/PLAIN; SizeOnDisk=5452; name="0MTG-P~1.TXT"; CHARSET=US-ASCII >Content-Description: 0MTG-P~1.TXT > >PUBLIC PARKING > >This information was extracted from San Jose City Web page >(url: http://www.sj-downtown.com/parking.htm) > >Convention Center Area (Also near the Children's Discovery Museum, >The Tech Museum, light rail stations, the Center for the Performing >Arts and the San Jose Main Library) > > Convention Center Garage (on Almaden Blvd. between San Carlos > and Woz Way) $5 flat rate days, $3 flat rate evenings. > > Auzerais and Woz Way (By the Children's Discovery Museum) > $2 flat rate. > > Almaden and Woz Wy . (near the Children's Discovery Museum, > close to light rail) $.75 first two 1/2 hours, $.50 each > 30 minutes thereafter. $12.50 daily maximum. $3 flat rate > evenings. > > Woz Wy. and Route 87 Lot (Woz Wy and Highway 87) $2 flat rate. > River Park Towers (corner of W. San Carlos and Woz Wy.) $.75 > each half hour, $10 maximum. > > St. Claire Hotel and Il fornio (302 S. Market St.) $4 valet parking. > > Hilton Hotel (300 Almaden Blvd.) $8 maximum self parking, > $10 12 hr valet parking. > >San Jose Arena Area > > San Jose Arena (525 W. Santa Clara St.) $7 or $10 arena parking. > > Santa Clara/87 Lot (Santa Clara St. and Route 87) $.75 first > 30 minutes, $.75 second 30 minutes, $.50 each 30 minutes > thereafter. $3 flat rate evenings, $12.50 daily maximum, $7.00 > Arena parking. > > Cahill Train Station (Cahill and San Fernando St.) $.50 all day. > > Julian St. and Autumn St. (Julian and Autumn) $7 or $10 Arena Events. > > >Central Downtown/Shopping District -- Near shops, hotels, >restaurants and The Pavilion > > Fountain Alley Lot (in the Fountain Alley between First St. > and Second St.) $.75 first 30 minutes, $.75 second 30 minutes, > $.50 each 30 minutes thereafter. $3 flat rate evenings, $12.50 > daily maximum. > > Fairmont Plaza Surface Lot (between Second St. and Third St. > on San Fernando) $.75 first 30 minutes, $.75 second 30 minutes, > $.50 each 30 minutes thereafter. $3 flat rate evenings, $12.50 > daily maximum. > > Fairmont Hotel (170 S. Market St.) $3 first half hour, $1 each > half hour thereafter, $15 maximum. > > Market St. and San Carlos St. $.60 each 20 minutes, $3 flat rate > evenings, $9.50 daily maximum. > > The Pavilion Garage (San Fernando St. Market St. and First St.) > $.75 first 30 minutes, $.75 second 30 minutes, $.50 each 30 minutes > thereafter. $3 flat rate evenings, $12.50 daily maximum. > > The Pavilion Lot (San Fernando St. Market St. and First St.) $.75 > first 30 minutes, $.75 second 30 minutes, $.50 each 30 minutes > thereafter. $3 flat rate evenings, $12.50 daily maximum. > > Market Post Towers (on Market St.) $.75 each 20 minutes, $10 maximum. > > >San Pedro Square -- Historic dining and entertainment district near >San Jose Arena > > Market St./San Pedro Square Garage (Santa Clara St. and San Pedro St.) > $.75 first 30 minutes, $.75 second 30 minutes, $.50 each 30 minutes > thereafter. $3 flat rate evenings, $12.50 daily maximum, $3.00 Arena > parking. > > Lot 2 (Corner of San Pedro St. and St. James St.) $3 flat fee. > > >SoFA District (South First Street Area) -- Near nightclubs, >restaurants and theaters > > Valley Title (Second St. and San Salvador St.) $.75 each half hour, > $6.50 maximum. > > Second/San Carlos Garage (Second St. and San Carlos St.) $.75 first > 30 minutes, $.75 second 30 minutes, $.50 each 30 minutes thereafter. > $3 flat rate evenings, $12.50 daily maximum. > > Next to YWCA (Third St. and San Salvador) $3 flat rate. > > >St. James Square Area -- Historic neighborhood and St. James Park > > Third St. Garage (St. John St. and Third St.) $.50 each 30 minutes, > $2 flat rate, daily maximum $11. > > St. James and St. John (between St. James St. and St. John St.) > $2 each hour, $7 maximum. > > >Almaden Boulevard Area -- Near office towers, the Center for the >Performing Arts, hotels and the San Jose Arena > > Holiday Inn (Almaden Blvd. between W. San Carlos and Park Ave.) > $4 all day, (pay upon exit), free for hotel guests. > > Almaden and Park Ave. (under Scott's Seafood) $.75 each half hour, > $10 maximum. > > Market St. and Devine St. (surface lot, between Market St. and > Devine St.) $3 flat rate. > > Park Center Plaza I (100 Park Center Plaza) $.75 each 20 minutes, > $10 maximum. > > San Pedro /Bassett Lot (San Pedro and Bassett St.) $2 flat rate > > Park Ave. and Highway 87 (Park and 87) $3 flat rate. > > >Santa Clara Street Area -- Near San Jose Arena, San Pedro Square and >office towers > > Pacific Western Bank (W. Santa Clara St. and Santa Teresa) $.75 > for per half hour for first two hours, $15 for 10 hours $22.50 > for 24 hrs. > > De Anza Hotel (233 W. Santa Clara St.) $3 valet only. > > Santa Clara St. and Terraine (Santa Clara St. and Terraine St.) > $.75 per half hour, $3.50 maximum. > > Almaden and Terraine (Almaden Blvd. and Terraine St.) $2 flat > fee Mon. - Fri.. > > Almaden and Santa Clara (Almaden Blvd. and Santa Clara St.) > $.50 per 20 minutes, $4 all day. > ------ > REGISTRATION FORM > 37th Internet Engineering Task Force - Page 1 of 2 > December 9-13, 1996 > San Jose, California, USA > >Please print or type: > >Name (Mr/Dr/Ms)__________________________________________________________ > >Title____________________________________________________________________ > >Organization_____________________________________________________________ > >Address__________________________________________________________________ > >_________________________________________________________________________ > >City_____________________________State_____________Postal Code___________ > >Country__________________________________________________________________ > >Telephone______________________________Fax_______________________________ > >Email____________________________________________________________________ > >Do you plan to attend the Sunday, DECEMBER 8th NEWCOMER'S ORIENTATION at >1530? > > YES___ NO___ > >Do you plan to attend the Sunday, DECEMBER 8th reception at 17:00? > > YES___ NO___ > >The IETF Proceedings are available electronically. Would you still >like a hard copy? > > YES___ NO ___ > >US$250.00 Registration postmarked on or BEFORE, Friday, November 8, 1996. >US$270.00 (US$250.00 + US$20.00 late fee) Registration postmarked after > Friday, November 8, 1996. > >Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check > > (U.S. dollars, drawn on a U.S. Bank), payable to: > Corporation for National Research Initiatives > >Account No.____________________________ Expiration Date__________________ > >Cardholder Name__________________________________________________________ > >Cardholder Signature_____________________________________________________ > >Registration Forms can be sent via electronic mail, facsimile, or postal mail: > > Electronic: ietf-rsvp@ietf.org > Facsimile: +1-703-758-5913 > Postal: Corporation for National Research Initiatives > Accounting Department - 37th IETF Meeting > 1895 Preston White Drive, Suite 100 > Reston, VA 20191-5434 USA > > > REGISTRATION FORM > 37th Internet Engineering Task Force - Page 2 of 2 > December 9-13, 1996 > San Jose, California, USA > > > >IMPORTANT: > > 1. Payment MAY, but does NOT have to, accompany the Form. > 2. As long as your Form is postmarked by the deadline date of > November 8, 1996, you are locked in to pay the lower registration > fee of $250.00 (e.g., send us your form via e-mail by the > deadline date and pay the $250.00 fee later via postal > mail). When paying by company check, be sure that your Accounting > Department knows that you qualified yourself for the lower rate. > 3. Payment is accepted on-site. > 4. Register ONE person per form. Substitutions are NOT allowed. > 5. Include a completed Registration Form with payment. > 6. Purchase orders are NOT accepted. > 7. DD Form 1556 IS accepted. > 8. We CANNOT invoice for payment. > 9. Registration Forms will be accepted via electronic mail and > facsimile until 1300ET on Wednesday, December 4, 1996. > 10. Requests for refunds must be received by 1700ET, Thursday, > December 5, 1996. No refunds will be processed beyond this > point. > 11. REFUND POLICY: Refunds are subject to a US$20.00 service charge. > Late fees WILL NOT be refunded. > 12. Your registration fee includes Sunday evening reception (cash bar), > and a daily continental breakfast and coffee breaks. > > > >For additional information or assistance, please contact +1-703-620-8990, >+1-703-758-5913 (Fax) or ietf-rsvp@ietf.org. Direct all inquiries >to: 37th IETF Meeting - San Jose, California, USA > ------ > > > > >Chapter 1 > > >IETF Overview > > > >The Internet Engineering Task Force (IETF) provides a forum for working >groups to coordinate technical developments of new protocols. Its most >important function is the development and selection of standards within >the Internet protocol suite. > >The IETF began in January 1986 as a forum for technical coordination by >contractors for the then US Defense Advanced Projects Agency (DARPA), >working on the ARPANET, US Defense Data Network (DDN), and the Internet >core gateway system. Since that time, the IETF has grown into a large >open international community of network designers, operators, vendors, >and researchers concerned with the evolution of the Internet >architecture and the smooth operation of the Internet. > >The IETF mission includes: > > > 1.Identifying and proposing solutions to pressing operational and > technical problems in the Internet; > > 2.Specifying the development or usage of protocols and the near-term > architecture, to solve technical problems for the Internet; > > 3.Facilitating technology transfer from the Internet Research Task > Force (IRTF) to the wider Internet community; and > > 4.Providing a forum for the exchange of relevant information within > the Internet community between vendors, users, researchers, agency > contractors, and network managers. > > >Technical activity on any specific topic in the IETF is addressed within >working groups. All working groups are organized roughly by function >into nine areas. Each is led by one or more area directors who have >primary responsibility for that one area of IETF activity. Together >with the Chair of the IETF/IESG, these technical directors compose the >Internet Engineering Steering Group (IESG). > >The current areas and directors which compose the IESG are: > > >IETF/IESG Chair Fred Baker fred@cisco.com >Applications Harald Alvestrand Harald.T.Alvestrand@uninett.no > Keith Moore moore+iesg@cs.utk.edu >Internet Frank Kastenholz kasten@ftp.com > Jeffrey Burgan jburgan@baynetworks.com >Network Management Deirdre Kostick kostick@qsun.att.com >Operational Requirements Scott Bradner sob@harvard.edu > Michael O'Dell mo@uunet.uu.net >Routing Joel Halpern jhalpern@newbridge.com >Security Jeff Schiller jis@mit.edu >Transport Allison Mankin mankin@isi.edu > Allyn Romanow allyn@eng.sun.com >User Services Joyce K. Reynolds jkrey@isi.edu > > > >The IETF has a Secretariat, headquartered at the Corporation for >National Research Initiatives in Reston, Virginia, with the following >staff: > > >IETF Executive Director Steve Coya scoya@ietf.org >IETF Meeting Coordinator Marcia Beaulieu mbeaulie@ietf.org >IETF Proceedings Editor/Webmaster Gehrett W. Ellis gellis@ietf.org >IETF Meeting Registrar Julie Kirchhoff juliek@ietf.org >IETF Internet-Drafts Administrator Cynthia Clark cclark@ietf.org > > > >The working groups conduct business during plenary meetings of the IETF, >during meetings outside of the IETF, and via electronic mail on mailing >lists established for each group. The IETF holds 4.5 day meetings three >times a year. These meetings are composed of working group sessions, >technical presentations, network status reports, working group >reporting, and an open IESG meeting. A Proceedings of each IETF plenary >is published, which includes reports from each area, each working group, >and each technical presentation. The Proceedings include a summary of >all current standardization activities. > >Meeting reports, charters (which include the working group mailing >lists), and general information on current IETF activities are available >on-line for anonymous FTP from several Internet hosts, including >ds.internic.net. > > > > 2 ------- Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 13 23:12:51 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA18370 for ipp-outgoing; Wed, 13 Nov 1996 23:12:30 -0500 (EST) Message-Id: <2.2.32.19961114015813.00950dfc@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Nov 1996 17:58:13 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Taking text from ISO?IEC 10175 OKed bu ISO Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Stan McConnell, who is the editor of the ISO/IEC 10175 documents wrote a message on our behalf some time back to ask if ISO had any objections to us reusing texts from the ISO DPA text. We have just received the following positive reply back from the ISO Central Secretariat: >From: "Brannon, Keith" >Message-Id: <3289B4B8@nc-gat01.iso.ch> >To: Stan McConnell >Cc: "Chabot, Jacques-Olivier" , > "Smith, Michael" >Subject: TR: Use of text from ISO/IEC 10175 >Encoding: 82 TEXT >X-Mailer: Microsoft Mail V3.0 > > >Stan, >Sorry it has taken us so long to come back to you and we apologise for this >delay.I can however confirm ,after discussing your request in-house, that we >have no problem with you developing an Internet form of DPA .We would >however be interested in receiving a copy of the final version. >Regards >Keith Brannon > ---------- Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Thu Nov 14 00:32:52 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA18946 for ipp-outgoing; Thu, 14 Nov 1996 00:28:14 -0500 (EST) Date: Wed, 13 Nov 96 21:15:14 PST From: Carl-Uno Manros Subject: FW: reminder of Internet-Draft cutoff date To: ipp@pwg.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi, just found this in my home mailbox. Carl-Uno ---------------Original Message--------------- This is just a reminder that the cutoff for Internet-Draft submissions prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at 1700 Eastern Standard US time. (I think that's 2200 UTC) Proposals to be discussed at IETF WG meetings must be submitted as Internet-Drafts prior to discussion. So if you want to have a proposal discussed at the San Jose IETF, you need to get it in before this deadline. Please also note that due to the the large number of last-minute internet-draft submissions, last-minute drafts require more time to appear in the Internet-Drafts repositories. Given the US Thanksgiving holidays on 28-29 November, I wouldn't expect last-minute drafts to be generally available before 2-3 December or so. So to give other working group members more time to review drafts, I encourage people to submit their drafts a few days before the deadline. For information on how to submit an Internet-Draft, look at ftp://ftp.ietf.org/ietf/1id-guidelines.txt Keith Moore APPS AD ----------End of Original Message---------- From ipp-archive Thu Nov 14 03:57:54 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id DAA19873 for ipp-outgoing; Thu, 14 Nov 1996 03:57:50 -0500 (EST) From: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 To: Carl-Uno Manros cc: ipp@pwg.org, moore@cs.utk.edu Subject: Re: Revised Charter Text In-reply-to: Your message of "Wed, 13 Nov 1996 09:54:20 PST." <2.2.32.19961113175420.0095af94@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Nov 1996 09:56:57 +0100 Message-ID: <5129.847961817@domen.uninett.no> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Carl-Uno, thanks for the clarification. Looking forward to the charter submission! Harald A From ipp-archive Thu Nov 14 08:57:57 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA20246 for ipp-outgoing; Thu, 14 Nov 1996 08:57:53 -0500 (EST) Message-Id: <199611141358.AA18173@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 14 Nov 96 8:56:57 EST Subject: Conference Call Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The next IPP conference call will be Wednesday, November 20 at 4PM EST (3 CST, 2 MST, 1 PST). The dial in number will be 1-423-673-6712, access code is 190148. I have reserved 25 lines and the call can last up to 2.5 hours. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 14 10:32:58 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA20527 for ipp-outgoing; Thu, 14 Nov 1996 10:29:58 -0500 (EST) Message-Id: <199611141530.AA21438@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 14 Nov 96 10:29:30 EST Subject: Minutes Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted an updated/fixed version of the minutes for the IPP session at the New Orleans PWG meeting. The various versions are: /pub/pwg/ipp/minutes/ipp-1196.doc /pub/pwg/ipp/minutes/ipp-1196.pdf /pub/pwg/ipp/minutes/ipp-1196.ps /pub/pwg/ipp/minutes/ipp-1196.txt I have also posted the minutes for the 11/13 conference call in the same formats as: /pub/pwg/ipp/minutes/ipp.conference.call.11-13.doc /pub/pwg/ipp/minutes/ipp.conference.call.11-13.pdf /pub/pwg/ipp/minutes/ipp.conference.call.11-13.ps /pub/pwg/ipp/minutes/ipp.conference.call.11-13.txt Happy hunting! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 14 14:18:01 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22699 for ipp-outgoing; Thu, 14 Nov 1996 14:14:43 -0500 (EST) Message-ID: <328B6E51.3AAE@sharplabs.com> Date: Thu, 14 Nov 1996 11:09:05 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: ipp@pwg.org Subject: Microsoft Internet Printing Efforts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I was wondering if we are going to align our IPP work with the internet printing effort currently underway at Microsoft. One of the engineers in my group attended a "Microsoft Windows/NT 5.0 Printing Architecture Preview" meeting at Microsoft this week, and there is a specific section within the handouts dedicated to internet printing utilizing HTTP and URLs. Some of the same concepts we talked about in New Orleans are being applied. I think we need to solicit participation by Microsoft in the IPP effort if they have already expended significant resources in the investigation of internet printing. It seems like their has been recent email from someone at Microsoft during our earlier internet printing discussions on the mailing list. Just a thought, Randy From ipp-archive Thu Nov 14 14:48:01 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA22872 for ipp-outgoing; Thu, 14 Nov 1996 14:45:28 -0500 (EST) Message-Id: <199611141946.AA29356@interlock.lexmark.com> To: Randy Turner Cc: "ipp%pwg.org" From: Don Wright Date: 14 Nov 96 14:46:05 EST Subject: Re: Microsoft Internet Printing Efforts Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I am fully aware of this effort and these are the folks I have been talking to trying to get them involved. Don To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: rturner%sharplabs.com @ interlock.lexmark.com (Randy Turner) @ SMTP Date: 11/14/96 11:09:05 AM Subject: Microsoft Internet Printing Efforts I was wondering if we are going to align our IPP work with the internet printing effort currently underway at Microsoft. One of the engineers in my group attended a "Microsoft Windows/NT 5.0 Printing Architecture Preview" meeting at Microsoft this week, and there is a specific section within the handouts dedicated to internet printing utilizing HTTP and URLs. Some of the same concepts we talked about in New Orleans are being applied. I think we need to solicit participation by Microsoft in the IPP effort if they have already expended significant resources in the investigation of internet printing. It seems like their has been recent email from someone at Microsoft during our earlier internet printing discussions on the mailing list. Just a thought, Randy From ipp-archive Thu Nov 14 15:08:02 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23061 for ipp-outgoing; Thu, 14 Nov 1996 15:07:30 -0500 (EST) Message-Id: <199611142008.AA00079@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 14 Nov 96 15:03:47 EST Subject: Conference Call Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The next IPP conference call will be Wednesday, November 20 at 4PM EST (3 CST, 2 MST, 1 PST). The dial in number will be 1-423-673-6712, access code is 190148. I have reserved 25 lines and the call can last up to 2.5 hours. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 14 15:08:03 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23040 for ipp-outgoing; Thu, 14 Nov 1996 15:07:22 -0500 (EST) Message-Id: <199611142008.AA00074@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 14 Nov 96 15:03:59 EST Subject: Minutes Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted an updated/fixed version of the minutes for the IPP session at the New Orleans PWG meeting. The various versions are: /pub/pwg/ipp/minutes/ipp-1196.doc /pub/pwg/ipp/minutes/ipp-1196.pdf /pub/pwg/ipp/minutes/ipp-1196.ps /pub/pwg/ipp/minutes/ipp-1196.txt I have also posted the minutes for the 11/13 conference call in the same formats as: /pub/pwg/ipp/minutes/ipp.conference.call.11-13.doc /pub/pwg/ipp/minutes/ipp.conference.call.11-13.pdf /pub/pwg/ipp/minutes/ipp.conference.call.11-13.ps /pub/pwg/ipp/minutes/ipp.conference.call.11-13.txt Happy hunting! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 14 15:28:02 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23255 for ipp-outgoing; Thu, 14 Nov 1996 15:26:02 -0500 (EST) Message-Id: <3.0b36.32.19961114122209.00c62bbc@pogo.wv.tek.com> X-Sender: andyd@pogo.wv.tek.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Thu, 14 Nov 1996 12:25:49 -0800 To: Don Wright From: Andy Davidson Subject: Re: Microsoft Internet Printing Efforts Cc: Randy Turner , "ipp%pwg.org" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO You must have had some effect, Don, because someone (no one I recognized from the PWG) asked Jim Livingston during the Q&A section if Microsoft was going to support the IPP effort of the PWG and his immediate response was "Yes, absolutely." andy At 02:46 PM 11/14/96 EST, Don Wright wrote: >I am fully aware of this effort and these are the folks I have been >talking to trying to get them involved. > >Don > >To: ipp%pwg.org @ interlock.lexmark.com @ SMTP >cc: (bcc: Don Wright) >From: rturner%sharplabs.com @ interlock.lexmark.com (Randy Turner) @ SMTP >Date: 11/14/96 11:09:05 AM >Subject: Microsoft Internet Printing Efforts > >I was wondering if we are going to align our IPP work with the >internet printing effort currently underway at Microsoft. One >of the engineers in my group attended a "Microsoft Windows/NT 5.0 >Printing Architecture Preview" meeting at Microsoft this week, and >there is a specific section within the handouts dedicated to >internet printing utilizing HTTP and URLs. Some of the same concepts >we talked about in New Orleans are being applied. > >I think we need to solicit participation by Microsoft in the IPP >effort if they have already expended significant resources in >the investigation of internet printing. It seems like their has >been recent email from someone at Microsoft during our earlier >internet printing discussions on the mailing list. > >Just a thought, > >Randy > > > > > From ipp-archive Thu Nov 14 15:33:02 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA23368 for ipp-outgoing; Thu, 14 Nov 1996 15:30:38 -0500 (EST) Message-Id: <199611142031.AA00983@interlock.lexmark.com> To: "pwg%pwg.org" , P1284_3 , "ipp%pwg.org" From: Don Wright Date: 14 Nov 96 15:29:36 EST Subject: Albuquerque Meeting Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Here are the meeting details for the Jan meetings in Albuquerque: Where: Albuquerque Marriott 2101 Louisiana Blvd Albuquerque, NM 87110 505-881-6800 When: Jan 6-10, 1997 Price: $99 Deadline: Dec 27, 1996 Schedule: Jan 6 1284.4 Jan 7 1284.4 Jan 8 1284.3 PWG - IPP Jan 9 1284.3 PWG - JMP, Sense Jan 10 PWG - PMP Please, please, please make your reservations early. It really helps with planning and determining the daily meeting charge if I have a good idea who is going to be there. Additionally, with overlapping meetings you might want to get your room early before they run out. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 14 16:58:03 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA23953 for ipp-outgoing; Thu, 14 Nov 1996 16:53:26 -0500 (EST) Date: Thu, 14 Nov 1996 13:53:23 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611142153.NAA19714@woden.eng.sun.com> To: pwg@pwg.org, P1284_3@lexmark.com, ipp@pwg.org, don@lexmark.com Subject: Re: Albuquerque Meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Is it possible to move the IPP part to Jan 9. I have a late afternoon meeting on the Jan 7 that makes it hard for me to arrive by the 8th. Bob Herriot > From don@lexmark.com Thu Nov 14 12:35:31 1996 > To: "pwg%pwg.org" , P1284_3 , > "ipp%pwg.org" > From: Don Wright > Date: 14 Nov 96 15:29:36 EST > Subject: Albuquerque Meeting > Mime-Version: 1.0 > Sender: owner-pwg@pwg.org > X-Lines: 37 > > Here are the meeting details for the Jan meetings in > Albuquerque: > > Where: Albuquerque Marriott > 2101 Louisiana Blvd > Albuquerque, NM 87110 > 505-881-6800 > > When: Jan 6-10, 1997 > > Price: $99 > > Deadline: Dec 27, 1996 > > Schedule: > > Jan 6 1284.4 > Jan 7 1284.4 > Jan 8 1284.3 PWG - IPP > Jan 9 1284.3 PWG - JMP, Sense > Jan 10 PWG - PMP > > Please, please, please make your reservations early. It > really helps with planning and determining the daily meeting > charge if I have a good idea who is going to be there. > Additionally, with overlapping meetings you might want to > get your room early before they run out. > > Don > > > ************************************************************* > * Don Wright (don@lexmark.com) Lexmark International * > * Manager Strategic Alliances * > * 740 New Circle Rd Phone: 606-232-4808 * > * Lexington, KY 40511 Fax: 606-232-6740 * > ************************************************************* > From ipp-archive Thu Nov 14 17:08:03 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA24377 for ipp-outgoing; Thu, 14 Nov 1996 17:04:18 -0500 (EST) Message-Id: <9611142100.AA20771@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Nov 1996 12:58:14 PST To: Don Wright From: Tom Hastings Subject: Re: Minutes Cc: "ipp%pwg.org" , pwg@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Don, Could you please stick with 8.3 file naming. Some of us are still with Windows 3.11. I think we can get the date for conference calls into 8 characters and some indication that its a conference call (maybe cc?). It might be nice to include the year in the file name too, since the date sometimes becomes today's date when copying files. If you put the year first, month next and day last, then it sorts by date. Maybe something like: cc961113.doc .pdf .ps .txt for weekly conference calls and ipp-9611.doc .pdf .ps .txt for monthly ipp meetings. Thanks, Tom At 12:03 11/14/96 PST, Don Wright wrote: >I have posted an updated/fixed version of the minutes for >the IPP session at the New Orleans PWG meeting. The >various versions are: > >/pub/pwg/ipp/minutes/ipp-1196.doc >/pub/pwg/ipp/minutes/ipp-1196.pdf >/pub/pwg/ipp/minutes/ipp-1196.ps >/pub/pwg/ipp/minutes/ipp-1196.txt > >I have also posted the minutes for the 11/13 conference >call in the same formats as: > >/pub/pwg/ipp/minutes/ipp.conference.call.11-13.doc >/pub/pwg/ipp/minutes/ipp.conference.call.11-13.pdf >/pub/pwg/ipp/minutes/ipp.conference.call.11-13.ps >/pub/pwg/ipp/minutes/ipp.conference.call.11-13.txt > >Happy hunting! > >Don > > >************************************************************* >* Don Wright (don@lexmark.com) Lexmark International * >* Manager Strategic Alliances * >* 740 New Circle Rd Phone: 606-232-4808 * >* Lexington, KY 40511 Fax: 606-232-6740 * >************************************************************* > > From ipp-archive Thu Nov 14 18:13:03 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA24826 for ipp-outgoing; Thu, 14 Nov 1996 18:10:26 -0500 (EST) Message-Id: <9611142300.AA20822@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Nov 1996 14:58:14 PST To: Don Wright From: Tom Hastings Subject: Re: Minutes Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Don, I tried giving a specific name for the destination on my PC FTP and it worked, so I can live with the long names. If you are going to have long names, I suggest that we include the year in the name. I also suggest that the year be more significant than the month and that the month be more significant than the day, so that sorted file name order is in date order. Thanks, Tom At 13:29 11/14/96 PST, you wrote: >I try to make everything as easy as possible but since 3.1 users >can name a file anything they want when they download, wouldn't >it be easier if the file name on the server side was very meaningful >so anyone looking for information would be able to find it? After finding >the a file, naming it according to you private conventions and within >the limitations of your OS should be minimal effort. > >I mean I can name it whatever you like but I have a terrible time >understanding what the pile of documents in the JMP section >are. Cryptic name, appreviations, acronyms -- what a pain!! I >always have to go get all the file dates and look for something >new rather than determining the content based upon the name. > >Don > >To: Don Wright >cc: ipp%pwg.org @ interlock.lexmark.com ("ipp%pwg.org") @ SMTP, pwg%pwg.org @ >interlock.lexmark.com @ SMTP >From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP >Date: 11/14/96 12:58:14 PM >Subject: Re: Minutes > >Don, > >Could you please stick with 8.3 file naming. Some of us are still with >Windows 3.11. I think we can get the date for conference calls into >8 characters and some indication that its a conference call (maybe cc?). > >It might be nice to include the year in the file name too, since the >date sometimes becomes today's date when copying files. > >If you put the year first, month next and day last, then it sorts by date. > >Maybe something like: > >cc961113.doc .pdf .ps .txt > >for weekly conference calls > >and > >ipp-9611.doc .pdf .ps .txt > >for monthly ipp meetings. > >Thanks, >Tom > >At 12:03 11/14/96 PST, Don Wright wrote: >>I have posted an updated/fixed version of the minutes for >>the IPP session at the New Orleans PWG meeting. The >>various versions are: >> >>/pub/pwg/ipp/minutes/ipp-1196.doc >>/pub/pwg/ipp/minutes/ipp-1196.pdf >>/pub/pwg/ipp/minutes/ipp-1196.ps >>/pub/pwg/ipp/minutes/ipp-1196.txt >> >>I have also posted the minutes for the 11/13 conference >>call in the same formats as: >> >>/pub/pwg/ipp/minutes/ipp.conference.call.11-13.doc >>/pub/pwg/ipp/minutes/ipp.conference.call.11-13.pdf >>/pub/pwg/ipp/minutes/ipp.conference.call.11-13.ps >>/pub/pwg/ipp/minutes/ipp.conference.call.11-13.txt >> >>Happy hunting! >> >>Don >> >> >>************************************************************* >>* Don Wright (don@lexmark.com) Lexmark International * >>* Manager Strategic Alliances * >>* 740 New Circle Rd Phone: 606-232-4808 * >>* Lexington, KY 40511 Fax: 606-232-6740 * >>************************************************************* >> >> > > > > > From ipp-archive Thu Nov 14 21:33:05 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA26472 for ipp-outgoing; Thu, 14 Nov 1996 21:28:32 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 11 Nov 1996 22:31:18 -0700 From: "Scott A. Isaacson" To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: IPP PING for IETF BOF Meeting on December 12 -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I am planning to attend. Scott Isaacson ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Nov 15 09:33:13 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28078 for ipp-outgoing; Fri, 15 Nov 1996 09:32:07 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002112490000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002112490000002*@MHS> To: , Subject: Ping - December IETF Meeting Date: Fri, 15 Nov 1996 09:29:27 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: I plan to attend. From ipp-archive Fri Nov 15 09:48:13 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA28240 for ipp-outgoing; Fri, 15 Nov 1996 09:48:10 -0500 (EST) Message-Id: <199611151448.AA17937@interlock.lexmark.com> To: Carl-Uno Manros , "ipp%pwg.org" From: Don Wright Date: 15 Nov 96 9:46:34 EST Subject: Ping - December IETF Meeting Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I will be there. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Fri Nov 15 11:08:14 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28441 for ipp-outgoing; Fri, 15 Nov 1996 11:05:37 -0500 (EST) Mime-Version: 1.0 Date: Fri, 15 Nov 1996 11:06:23 -0500 Message-Id: <000089F2.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: Ping - December IETF Meeting To: Carl-Uno Manros , "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: first-class Status: RO I plan to attend (I will even pay the fee!) Bill Wagner, DPI, Division of Osicom Technologies From ipp-archive Fri Nov 15 11:43:15 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA28610 for ipp-outgoing; Fri, 15 Nov 1996 11:42:46 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002116601000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002116601000002*@MHS> To: , Date: Fri, 15 Nov 1996 11:40:34 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: I will attend the IETF BOF. Roger deBry From ipp-archive Fri Nov 15 12:28:14 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA28799 for ipp-outgoing; Fri, 15 Nov 1996 12:24:58 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 15 Nov 1996 10:21:31 -0700 From: Rob Whittle To: cmanros@cp10.es.xerox.com Cc: ipp@pwg.org Subject: Ping - December IETF Meeting Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I will be there. Rob Whittle Product Line Manager Advanced Network Services Novell 801-861-7240 From ipp-archive Fri Nov 15 15:18:16 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA29746 for ipp-outgoing; Fri, 15 Nov 1996 15:17:39 -0500 (EST) Date: Fri, 15 Nov 1996 12:14:18 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611152014.MAA20672@woden.eng.sun.com> To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: Ping - December IETF Meeting X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I plan to be there. > From don@lexmark.com Fri Nov 15 06:49:06 1996 > To: Carl-Uno Manros , "ipp%pwg.org" > > From: Don Wright > Date: 15 Nov 96 9:46:34 EST > Subject: Ping - December IETF Meeting > Mime-Version: 1.0 > Sender: ipp-owner@pwg.org > X-Lines: 12 > > I will be there. > > Don > > > > ************************************************************* > * Don Wright (don@lexmark.com) Lexmark International * > * Manager Strategic Alliances * > * 740 New Circle Rd Phone: 606-232-4808 * > * Lexington, KY 40511 Fax: 606-232-6740 * > ************************************************************* > From ipp-archive Fri Nov 15 18:05:19 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA00873 for ipp-outgoing; Fri, 15 Nov 1996 18:00:56 -0500 (EST) Message-Id: <9611152301.AA21498@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 1996 14:59:14 PST To: ipp@pwg.org From: Tom Hastings Subject: updated presentation charts from IBM on IPP and HTTP Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've posted the .ps file for Roger for the updated presentation charts that IBM presented at the PWG meeting last week: ftp://ftp.pwg.org/pub/pwg/ipp/htpp/httpnew.ps -rw-r--r-- 1 pwg pwg 1211341 Nov 15 22:56 httpnew.ps >Return-Path: >From: rdebry@us1.ibm.com >X400-Originator: rdebry@us1.ibm.com >X400-Recipients: non-disclosure:; >X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002088682000002] >X400-Content-Type: P2-1988 (22) >To: <"Scott_isaacson@NOVELL.COM"@??.ibm.com>, , > >Subject: updated presentation charts >Date: Thu, 14 Nov 1996 15:48:06 PST > >Classification: >Prologue: >Epilogue: > >Attached is a postscript file of the updated HTPP charts presented in New >Orleans. Can someone post to the PWG ftp-site? I can't. > > > >Attachment Converted: C:\HASTINGS\ATTACH\httpnew.ps > From ipp-archive Mon Nov 18 12:12:29 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA05630 for ipp-outgoing; Mon, 18 Nov 1996 12:10:11 -0500 (EST) Message-Id: <3.0.32.19961115123033.00a5b7d0@crash.cts.com> X-Sender: raylutz@crash.cts.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Mon, 18 Nov 1996 09:06:21 -0800 To: cmanros@cp10.es.xerox.com, ipp@pwg.org From: Raymond Lutz Subject: Re: Ping - December IETF Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I plan to be there. /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair MFPA: 1-800-603-MFPA ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ From ipp-archive Mon Nov 18 15:47:32 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06220 for ipp-outgoing; Mon, 18 Nov 1996 15:45:29 -0500 (EST) Message-Id: <199611182046.AA06980@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 18 Nov 96 15:44:28 EST Subject: Conference Call Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Just in case anyone missed this because of the mailing list hiccup.... Don To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: From: Don Wright Date: 11/14/96 08:56:57 AM Subject: Conference Call The next IPP conference call will be Wednesday, November 20 at 4PM EST (3 CST, 2 MST, 1 PST). The dial in number will be 1-423-673-6712, access code is 190148. I have reserved 25 lines and the call can last up to 2.5 hours. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Nov 18 15:47:32 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA06221 for ipp-outgoing; Mon, 18 Nov 1996 15:45:30 -0500 (EST) Message-Id: <199611182046.AA06984@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 18 Nov 96 15:43:48 EST Subject: IPP Requirements Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have placed my first draft of the ID for requirements for IPP on the ftp server. The files are located in the ipp/drafts directory. Unfortunately, the full URL is too long for a SMTP note's width so I have only included the file names below: draft-wright-ipp-req-01.doc draft-wright-ipp-req-01.pdf draft-wright-ipp-req-01.ps For some reason, I can't get WORD to generate a nice flat text file with the headers and footers to look like an internet draft. Anyone got any ideas? Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Nov 18 19:47:33 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA07905 for ipp-outgoing; Mon, 18 Nov 1996 19:45:08 -0500 (EST) Message-Id: <199611190045.TAA07900@lists.underscore.com> Date: Mon, 18 Nov 96 17:18:41 MST From: "Harry Lewis " To: ipp@pwg.org Subject: Proposed well known port for printing via HTTP Sender: ipp-owner@pwg.org Precedence: first-class Status: RO In the IPP/1.0 draft version 0.91 (11/14), on PDF (no revision marks) line 474, there is reference to a sample (hypothetical) IPP Job name. The name is made up of the http protocol indicator, the IP address of the printer, the "port" and the printer name. Here, the port is an arbitrary example. http://1.2.3.4:3042/printer-2 I would like to propose we attempt to standardize a well known port for printing via http. The notion would be that whatever we define as printing via http will work over http well known port 80 (along with everything else that flows via http), but, if directed to well known port (say 380 - assuming this port is not already defined), then only PRINTING, not any other form of http, would be expected. This proposal closely follows the motivation described in the internet draft submitted June 1996, which recommends well known port 280 for SNMP over HTTP. Read (3) of this draft for a more thorough dissertation on the merits of this approach. As for text to add to the IPP draft (tonight), I suggest a new head level created between 2 (Distributed Printing) and 3 (IPP Objects) called 2 (Printing via HTTP). Probably, a lot could be lifted from Roger's document and put into this section, I'm not going to try and flesh this out here. Also, in this section, however, we should put some words like... "It will be suggested (in section 5) that Clients identify Printer objects using an HTTP type URL. One element of this proposal will be to further recommend the establishment, through IANA, of a well known port (380 recommended) for printing via HTTP. The purpose of this well known port would be to distinguish printing from non-printing content. While any acceptable HTTP content could be inter-mixed over HTTP well known port 80, only HTTP printing would be acceptable on port 380. The remainder of this draft will define the IPP content for HTTP printing, including IPP objects, operations, naming and attributes." Harry Lewis - IBM Printing Systems From ipp-archive Mon Nov 18 20:47:34 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08393 for ipp-outgoing; Mon, 18 Nov 1996 20:47:27 -0500 (EST) Message-Id: <2.2.32.19961119012913.00928424@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 17:29:13 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Locating Printers Sender: ipp-owner@pwg.org Precedence: first-class Status: RO In Harald Alvestrand's comments to our early PWG draft for Charter, it was pointed out that we need to look into what the Service Location (SVRLOC) WG in IETF has produced. It turns out that they have a rather substantial draft (57 pages) as Internet-Draft: ftp://ietf.org/internet-drafts/draft-ietf-svrloc-protocol-14.txt Among the listed authors are: Erik Guttman Sun Microsystems 2550 Garcia Avenue, MS PAL01-550 Mountain View, CA 94043-1100 Phone: +1 415 336 6697 Email: Erik.Guttman@eng.sun.com AND Charles Perkins IBM Corporation P.O. Box 704 Yorktown Heights NY 10598 Phone: +1 914 784 7350 Fax: +1 914 784 6205 E-mail: perk@watson.ibm.com Any chance that you guys from Sun and IBM could do some internal liason work to get a quick view on what these folks think about the adviceability to use the SVRLOC stuff to meet some of our objectives (including the 6 month's goal)? Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 18 22:17:36 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08601 for ipp-outgoing; Mon, 18 Nov 1996 22:16:05 -0500 (EST) Message-Id: <2.2.32.19961119030441.00901220@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 19:04:41 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Draft for IETF IPP WG Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Below is my attempt to produce a draft for the IETF charter that is short and general enough. I have taken out most of the details that concerns requirements and have tried to take Harald's earlier comments into account. Let us review this version in our Wednesday phone conference. If you want things added, please also suggest what you want to remove instead, as this is about the right amount of text that Harald declared that he is willing to accept. Regards, Carl-Uno --- (DRAFT 11/18/96) IETF Internet Printing Protocol (ipp) WG Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: TBD Mailing List Information: General Discussion: To Subscribe: Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources such as printers and shared documents and then printing using those resources. The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. The protocol shall support a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). The working group shall leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. For location of printers, the working group shall leverage existing standards for directories and emerging standards for service location. The working group shall coordinate its activities with other printing-related standards bodies. The working group shall define solutions that do not preclude the notion of multi-tiered configurations consisting of both logical and physical printers. Also, the new job submission protocol should not preclude submitting jobs to any type of output device (e.g., fax, printer, gateway). Also, the working group shall define extensibility paths so that similar extensions will interoperate and proprietary, dissimilar extensions will never conflict. This working group may define work that will replace RFC 1179 'Line Printer Daemon Protocol'. LPR/LPD was designed a long time ago with line printers in mind. It does not fit with current page oriented printing technologies. Deliverables and Milestones: Done Mailing list and archive November 1996 - Submit first set of Internet-Drafts December 1996 - BOF in IETF meeting in San Jose, CA, USA March 1997 - Submit Internet-Drafts April 1997 - Review of specification in IETF meeting in Memphis, TN, USA May 1997 - At least 2 implemented protypes May 1997 - Submit document to the IESG for Proposed Standard Internet-Drafts: No Current Internet-Drafts Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 18 22:42:36 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08754 for ipp-outgoing; Mon, 18 Nov 1996 22:39:02 -0500 (EST) Message-Id: <2.2.32.19961119032750.0093dfe4@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 19:27:50 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Suggested Agenda for Phone Conference Wednesday - November 20 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Review home work assignments on: - Charter text for IETF WG (Carl-Uno) - Requirements (Don) - Attributes (Bob, Roger, Scott, Tom) - Use of Directory (Keith, Scott) Issues: - Using SVRLOC protocol and/or LDAP to locate printers? - Alternative ways of using HTTP for printing? Preparations for San Jose BOF on December 12: - Check agenda - Check planned participation - Determine which Internet-Drafts we want to submit by Friday Potential overlap with IETF FAX activities: - Compare charter texts and other input Plan further work between now and San Jose ----- If you have further subjects you want to have covered, please send a message to the list with your wishes ASAP. Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 18 23:50:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA08951 for ipp-outgoing; Mon, 18 Nov 1996 23:43:04 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 18 Nov 1996 20:18:09 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: Directory Entry Schema Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Keith Carter and I met and we want to run the following issues by the team: We want to have a Location attribute. We propose that this should be a " a free form string that can contain any site specific location information." How should filtered searches work on values of this attribute? We want to introduce a new attribute callled Print Quality. "This indicates a somewhat subjective evaluation of the overall printing quality: "high", "medium", or "low" " ISSUE: Does this subsume the need for Resolution and Speed? We want to introduce a new attribute called Cost. "This indicates a somewhat subjective evaluation of the overall cost of printing at this printer: "high", "medium", or "low". " ISSUE: Is this a good thing or not? We propose a Fonts Supported attribute which is the same as the fonts-supported attribute in the Printer object. ISSUE: Do you agree that this should be in the directory entry. Some studies have shown that users want to search for printers based on this attribute. If we keep Maximum Speed should it be moved to "high, med low"?? We propose a P1284 Device ID not a plug and play Id -- the plug and play id can be created from this. ISSUE: Does this subsume the need for Make, Model, and Type?? ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Tue Nov 19 02:57:43 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA09917 for ipp-outgoing; Tue, 19 Nov 1996 02:55:46 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 19 Nov 1996 00:54:51 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP 0.92 is in drafts Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I forgot to mention that I put v 0.92 in the drafts directory Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Tue Nov 19 02:57:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA09827 for ipp-outgoing; Tue, 19 Nov 1996 02:55:10 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 19 Nov 1996 00:34:08 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP Version 0.92 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO As promised, I have put a new version of our IPP Internet-Draft on the ftp server. It is called: ipp92rev.pdf With rev marks PDF file ipp92rev.doc " " Doc file ipp92.pdf With no rev marks PDF file ipp92.doc " " Doc file Note that the rev marks are agains version 0.91 not the one the document that we reviewed last week. The section on IPP Operations Using HTTP and how to encode IPP Operations is brand new, it just got thrown in. Roger did a good job of pulling it together, but it probably doesn't fit very well in the doc where it is and it hasn't been reviewe at all. ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Tue Nov 19 02:57:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA09860 for ipp-outgoing; Tue, 19 Nov 1996 02:55:24 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 19 Nov 1996 00:38:13 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org, harryl@VNET.IBM.COM Subject: Proposed well known port for printing via HTTP -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Harry, You won't find this suggestion in the 0.92 version that I just put on the ftp server. It is not becuase your write up wasn't superb (which is was), it is jus that it is late and I forgot!!!. I will add it to the next version. Thanks. Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> "Harry Lewis " 11/18/96 05:18pm >>> In the IPP/1.0 draft version 0.91 (11/14), on PDF (no revision marks) line 474, there is reference to a sample (hypothetical) IPP Job name. The name is made up of the http protocol indicator, the IP address of the printer, the "port" and the printer name. Here, the port is an arbitrary example. http://1.2.3.4:3042/printer-2 I would like to propose we attempt to standardize a well known port for printing via http. The notion would be that whatever we define as printing via http will work over http well known port 80 (along with everything else that flows via http), but, if directed to well known port (say 380 - assuming this port is not already defined), then only PRINTING, not any other form of http, would be expected. This proposal closely follows the motivation described in the internet draft submitted June 1996, which recommends well known port 280 for SNMP over HTTP. Read (3) of this draft for a more thorough dissertation on the merits of this approach. As for text to add to the IPP draft (tonight), I suggest a new head level created between 2 (Distributed Printing) and 3 (IPP Objects) called 2 (Printing via HTTP). Probably, a lot could be lifted from Roger's document and put into this section, I'm not going to try and flesh this out here. Also, in this section, however, we should put some words like... "It will be suggested (in section 5) that Clients identify Printer objects using an HTTP type URL. One element of this proposal will be to further recommend the establishment, through IANA, of a well known port (380 recommended) for printing via HTTP. The purpose of this well known port would be to distinguish printing from non-printing content. While any acceptable HTTP content could be inter-mixed over HTTP well known port 80, only HTTP printing would be acceptable on port 380. The remainder of this draft will define the IPP content for HTTP printing, including IPP objects, operations, naming and attributes." Harry Lewis - IBM Printing Systems From ipp-archive Tue Nov 19 09:07:42 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA11601 for ipp-outgoing; Tue, 19 Nov 1996 09:03:28 -0500 (EST) Message-Id: <199611191404.AA22806@interlock.lexmark.com> To: "harryl%vnet.ibm.com" Cc: "ipp%pwg.org" From: Don Wright Date: 19 Nov 96 9:01:56 EST Subject: Re: Proposed well known port for printing via HTTP Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Dedicating a port to printing on the surface sounds good. But, not being an expert on firewalls, I ask is that a problem? My understanding is that some firewalls keep things under control by not allowing certains ports to be used (i.e. nothing can be used unless explicitly permitted.) Is this going to be a problem in an inter-enterprise environment? Could someone with a better understanding of firewalls comment on this? Don To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: harryl @ vnet.ibm.com>" submitted June 1996, which recommends well known port 280 for SNMP over HTTP. Read (3) of this draft for a more thorough dissertation on the merits of this approach. As for text to add to the IPP draft (tonight), I suggest a new head level created between 2 (Distributed Printing) and 3 (IPP Objects) called 2 (Printing via HTTP). Probably, a lot could be lifted from Roger's document and put into this section, I'm not going to try and flesh this out here. Also, in this section, however, we should put some words like... "It will be suggested (in section 5) that Clients identify Printer objects using an HTTP type URL. One element of this proposal will be to further recommend the establishment, through IANA, of a well known port (380 recommended) for printing via HTTP. The purpose of this well known port would be to distinguish printing from non-printing content. While any acceptable HTTP content could be inter-mixed over HTTP well known port 80, only HTTP printing would be acceptable on port 380. The remainder of this draft will define the IPP content for HTTP printing, including IPP objects, operations, naming and attributes." Harry Lewis - IBM Printing Systems From ipp-archive Tue Nov 19 11:07:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12254 for ipp-outgoing; Tue, 19 Nov 1996 11:06:32 -0500 (EST) Message-Id: <199611191607.AA27361@interlock.lexmark.com> To: Carl-Uno Manros Cc: "ipp%pwg.org" From: Don Wright Date: 19 Nov 96 11:03:45 EST Subject: Re: Draft for IETF IPP WG Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have a couple of suggestions: 1) We really must include somewhere in the charter that we will be relying on WEB Browsers, HTTP, etc. for much of the underlying plumbing. 2) I think the sentence on "multi-tiered configurations" can be removed since it is covered in the requirements document and is not mainstream to the goals. Don To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: cmanros%cp10.es.xerox.com @ interlock.lexmark.com (Carl-Uno Manros) @ SMTP Date: 11/18/96 07:04:41 PM Subject: Draft for IETF IPP WG Below is my attempt to produce a draft for the IETF charter that is short and general enough. I have taken out most of the details that concerns requirements and have tried to take Harald's earlier comments into account. Let us review this version in our Wednesday phone conference. If you want things added, please also suggest what you want to remove instead, as this is about the right amount of text that Harald declared that he is willing to accept. Regards, Carl-Uno --- (DRAFT 11/18/96) IETF Internet Printing Protocol (ipp) WG Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: TBD Mailing List Information: General Discussion: To Subscribe: Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources such as printers and shared documents and then printing using those resources. The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. The protocol shall support a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). The working group shall leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. For location of printers, the working group shall leverage existing standards for directories and emerging standards for service location. The working group shall coordinate its activities with other printing-related standards bodies. The working group shall define solutions that do not preclude the notion of multi-tiered configurations consisting of both logical and physical printers. Also, the new job submission protocol should not preclude submitting jobs to any type of output device (e.g., fax, printer, gateway). Also, the working group shall define extensibility paths so that similar extensions will interoperate and proprietary, dissimilar extensions will never conflict. This working group may define work that will replace RFC 1179 'Line Printer Daemon Protocol'. LPR/LPD was designed a long time ago with line printers in mind. It does not fit with current page oriented printing technologies. Deliverables and Milestones: Done Mailing list and archive November 1996 - Submit first set of Internet-Drafts December 1996 - BOF in IETF meeting in San Jose, CA, USA March 1997 - Submit Internet-Drafts April 1997 - Review of specification in IETF meeting in Memphis, TN, USA May 1997 - At least 2 implemented protypes May 1997 - Submit document to the IESG for Proposed Standard Internet-Drafts: No Current Internet-Drafts Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 11:12:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12403 for ipp-outgoing; Tue, 19 Nov 1996 11:08:33 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002172642000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002172642000002*@MHS> To: Subject: Directory Entry Schema Date: Tue, 19 Nov 1996 11:08:10 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/19/96 08:37 AM --------------------------- ipp-owner @ pwg.org 11/18/96 09:46 PM To: ipp @ pwg.org@internet cc: Subject: Directory Entry Schema >>Keith Carter and I met and we want to run the following issues by the >>team: >>We want to have a Location attribute. We propose that this should be a " >>a free form string that can contain any site specific location information." >>How should filtered searches work on values of this attribute? Scott, I assume that you are talking about adding the existing printer location attribute (section 6.4.2) to the directory schema, not inventing a new attribute. Perhaps we could recommend that attribute values, although being free-form text, be written as dotted values, e.g. Provo.Building3.floor2, that way installation specific filtering (e.g. find all printers in building3) could perhaps be done more easily. >>We want to introduce a new attribute callled Print Quality. "This indicates >>a somewhat subjective evaluation of the overall printing quality: "high", >>"medium", or "low" " ISSUE: Does this subsume the need for Resolution >>and Speed? Again I assume that you are adding the existing print qualities supported attribute to the directory schema, not inventing a new attribute. I think that quality is an attribute that can often be orthogonal to speed and resolution. For example, some printers reduce the qulaity by putting down less toner while still printing at the same speed and resolution. >>We want to introduce a new attribute called Cost. "This indicates a >>somewhat subjective evaluation of the overall cost of printing at this >>printer: "high", "medium", or "low". " ISSUE: Is this a good thing or not? This makes sense to me when in an intranet environment where controlling costs would be important. In an internet environment where I might be paying for a print job at Kinkos, for example, I think we might want some alternative schemes. One idea might be to allow a print job to be sumbitted with a "bid" attribute. The bid attribute says "don't print this, but tell me what it will cost to print this job". In an intranet environment would we want more granularity than high-medium-low? For example, let an installation define the number of "chits" required to print on any given printer, then put this number in the cost attribute. Thus if I had a templare for printing color foils, it might cost 10 "chits", while printing two-up on a high speed fanfold printer costs 1 "chit". Chits don't necesarily have to relate to exact costs, but can provide a relative cost. We'd probably want to associate these with templates, since cost is a funcntion of the media, n-up, use of color, and so on. >>We propose a Fonts Supported attribute which is the same as the >>fonts-supported attribute in the Printer object. ISSUE: Do you agree that >>this should be in the directory entry. Some studies have shown that >>users want to search for printers based on this attribute. Could there be some way of indicating some "standard" font sets rather than enumerate the entire list in the printer (including fonts that could be downloaded transparently from a server)? Would a lagre enterprise want to have installation defined "sets"? >>If we keep Maximum Speed should it be moved to "high, med low"?? >>We propose a P1284 Device ID not a plug and play Id -- the plug and play >>id can be created from this. ISSUE: Does this subsume the need for Make, Model, and Type?? ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Tue Nov 19 11:17:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12580 for ipp-outgoing; Tue, 19 Nov 1996 11:14:49 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002172775000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002172775000002*@MHS> To: Subject: Locating Printers Date: Tue, 19 Nov 1996 11:14:27 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: We have had quite a bit of discussion on this internally in IBM, and the results communicated to Scott Isaacson. I think that Keith Carter and Scott have met to discuss the issues and work on a proposal ... ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/19/96 09:12 AM --------------------------- ipp-owner @ pwg.org 11/18/96 06:51 PM To: ipp @ pwg.org@internet cc: Subject: Locating Printers In Harald Alvestrand's comments to our early PWG draft for Charter, it was pointed out that we need to look into what the Service Location (SVRLOC) WG in IETF has produced. It turns out that they have a rather substantial draft (57 pages) as Internet-Draft: ftp://ietf.org/internet-drafts/draft-ietf-svrloc-protocol-14.txt Among the listed authors are: Erik Guttman Sun Microsystems 2550 Garcia Avenue, MS PAL01-550 Mountain View, CA 94043-1100 Phone: +1 415 336 6697 Email: Erik.Guttman@eng.sun.com AND Charles Perkins IBM Corporation P.O. Box 704 Yorktown Heights NY 10598 Phone: +1 914 784 7350 Fax: +1 914 784 6205 E-mail: perk@watson.ibm.com Any chance that you guys from Sun and IBM could do some internal liason work to get a quick view on what these folks think about the adviceability to use the SVRLOC stuff to meet some of our objectives (including the 6 month's goal)? Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 12:52:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA13696 for ipp-outgoing; Tue, 19 Nov 1996 12:50:08 -0500 (EST) Message-ID: <3291F1F6.2DD6@sharplabs.com> Date: Tue, 19 Nov 1996 09:44:22 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: "Scott A. Isaacson" CC: ipp@pwg.org Subject: Re: Directory Entry Schema References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott A. Isaacson wrote: > > Keith Carter and I met and we want to run the following issues by the > team: > > We want to have a Location attribute. We propose that this should be a " > a free form string that can contain any site specific location information." > How should filtered searches work on values of this attribute? If this string contains site-specific information, then standardized filtered searches would only work with a pre-defined nomenclature using keywords and/or some type of BNF or fairly rigid syntax. Keywords could be defined, with the associated values being the secondary key components (the first search component being the keyword in a "search by keyword-value pair" scenario). I would offer that there is a URN (Uniform Resource Name) working group looking into persistance and location-based naming for network resources. I believe drafts are available on their current work. Also, since this information is site-specific, does it suggest a usefulness only in the "intranet" domain, as opposed to "internet" domain? > > We want to introduce a new attribute callled Print Quality. "This indicates > a somewhat subjective evaluation of the overall printing quality: "high", > "medium", or "low" " ISSUE: Does this subsume the need for Resolution > and Speed? I do think that "print quality" might obviate the need for resolution, but probably not for speed, since alot of the time (depending on the device) they could be inversely proportional. (i.e., it quicker to print "draft" than "highest-resolution"). > > We want to introduce a new attribute called Cost. "This indicates a > somewhat subjective evaluation of the overall cost of printing at this > printer: "high", "medium", or "low". " ISSUE: Is this a good thing or not? We could also assume here that cost might be directly proportional to "print quality" mentioned in the previous paragraph. Some 1st order normalization of these attributes is obviously going to be a key goal of future meetings. > > We propose a Fonts Supported attribute which is the same as the > fonts-supported attribute in the Printer object. ISSUE: Do you agree that > this should be in the directory entry. Some studies have shown that > users want to search for printers based on this attribute. > > If we keep Maximum Speed should it be moved to "high, med low"?? > > We propose a P1284 Device ID not a plug and play Id -- the plug and play > id can be created from this. ISSUE: Does this subsume the need for > Make, Model, and Type?? It probably would if the only path to the particular device pointed to by this entry is via a 1284 interface. Just my $0.02 (or more) Randy > > ************************************************************ > Scott A. Isaacson > Print Services Consulting Engineer > Novell Inc., 122 E 1700 S, Provo, UT 84606 > V: (801) 861-7366, (800) 453-1267 x17366 > F: (801) 861-4025, E: scott_isaacson@novell.com > W: http://www.novell.com > ************************************************************ From ipp-archive Tue Nov 19 14:02:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA13959 for ipp-outgoing; Tue, 19 Nov 1996 13:58:33 -0500 (EST) Message-Id: <199611191859.AA02882@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 19 Nov 96 13:58:09 EST Subject: -No Subject- Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO For those of you who have not been involved in the W3C, please check out: http://www.w3.org/pub/WWW/Printing/ for the W3C's activity on WEB Printing. Some of it is applicable to the work we are doing while most of it is related to printing HTML. There is a pointer to our BOF in San Jose at the top of this page that Dave Raggett has added per my request. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Tue Nov 19 14:07:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14233 for ipp-outgoing; Tue, 19 Nov 1996 14:05:23 -0500 (EST) Message-Id: <2.2.32.19961119174614.00939b4c@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 09:46:14 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: Proposed well known port for printing via HTTP Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 04:18 PM 11/18/96 PST, you wrote: >Also, in this section, however, we should put some words like... > > "It will be suggested (in section 5) that Clients identify Printer objects > using an HTTP type URL. One element of this proposal will be to further > recommend the establishment, through IANA, of a well known port (380 > recommended) for printing via HTTP. The purpose of this well known port > would be to distinguish printing from non-printing content. While any > acceptable HTTP content could be inter-mixed over HTTP well known port 80, > only HTTP printing would be acceptable on port 380. > > The remainder of this draft will define the IPP content for HTTP printing, > including IPP objects, operations, naming and attributes." > >Harry Lewis - IBM Printing Systems > Harry, I brought up this subject with Larry Masinter (who is the IETF HTTP Chair) when I met him last week. He claims that the HTTP does not really care about the port number and that hence it would be no point in using a different number fore the printing protocol. Can somebody else, who is supplying Web servers, verify this? Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 14:07:46 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14103 for ipp-outgoing; Tue, 19 Nov 1996 14:04:01 -0500 (EST) Mime-Version: 1.0 Date: Tue, 19 Nov 1996 14:06:10 -0500 Message-Id: <00008FBD.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: Draft for IETF IPP WG 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: first-class Status: RO Some reactions to the draft: I thought that finding shared documents, as identified in the first sentence, would be left to other web-oriented groups and that IPP was concerned with locating and using output devices. Since the statement says that locating shared documents is part of internet printing, it suggests that it is part of the IPP project. I would suggest dropping the reference to shared documents. I did not expect the strong statement with regard to authentication, authorization, etc. Is this regarded as primary (shall) to the group's activities? I was surprised by the very tentative "may define work that will replace RFC 1159". I thought this was a definite objective and one with which IP printing users could identify. Bill Wagner, DPI ______________________________ (DRAFT 11/18/96) IETF Internet Printing Protocol (ipp) WG Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: TBD Mailing List Information: General Discussion: To Subscribe: Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources such as printers and shared documents and then printing using those resources. The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. The protocol shall support a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). The working group shall leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. For location of printers, the working group shall leverage existing standards for directories and emerging standards for service location. The working group shall coordinate its activities with other printing-related standards bodies. The working group shall define solutions that do not preclude the notion of multi-tiered configurations consisting of both logical and physical printers. Also, the new job submission protocol should not preclude submitting jobs to any type of output device (e.g., fax, printer, gateway). Also, the working group shall define extensibility paths so that similar extensions will interoperate and proprietary, dissimilar extensions will never conflict. This working group may define work that will replace RFC 1179 'Line Printer Daemon Protocol'. LPR/LPD was designed a long time ago with line printers in mind. It does not fit with current page oriented printing technologies. Deliverables and Milestones: Done Mailing list and archive November 1996 - Submit first set of Internet-Drafts December 1996 - BOF in IETF meeting in San Jose, CA, USA March 1997 - Submit Internet-Drafts April 1997 - Review of specification in IETF meeting in Memphis, TN, USA May 1997 - At least 2 implemented protypes May 1997 - Submit document to the IESG for Proposed Standard Internet-Drafts: No Current Internet-Drafts Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 14:22:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14407 for ipp-outgoing; Tue, 19 Nov 1996 14:20:53 -0500 (EST) Message-Id: <2.2.32.19961119191539.0092d100@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 11:15:39 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: IPP Version 0.92 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 11:34 PM 11/18/96 PST, you wrote: >The section on IPP Operations Using HTTP and how to encode IPP >Operations is brand new, it just got thrown in. Roger did a good job of >pulling it together, but it probably doesn't fit very well in the doc where it >is and it hasn't been reviewe at all. > >Scott A. Isaacson Scott, do you expect that we can have a coherent version by the end of the week to send to the IETF? If not, I suggest that we limit ourselves to sending the Requirements documents at this stage and wait with sending the major document until after the IETF meeting in December. Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 14:37:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14574 for ipp-outgoing; Tue, 19 Nov 1996 14:33:11 -0500 (EST) Message-Id: <199611191933.AA04242@interlock.lexmark.com> To: Carl-Uno Manros Cc: "ipp%pwg.org" From: Don Wright Date: 19 Nov 96 14:31:14 EST Subject: Re: Proposed well known port for printing via HTTP Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Carl-Uno: That is correct. HTTP is port independent; however, the server would like very much to know which port/ports to listen to for requests. Therefore, it is quite possible to bring up different default pages when requesting on one port versus another but the HTTP protocol is really unchanged. Don To: ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: cmanros%cp10.es.xerox.com @ interlock.lexmark.com (Carl-Uno Manros) @ SMTP Date: 11/19/96 09:46:14 AM Subject: Re: Proposed well known port for printing via HTTP At 04:18 PM 11/18/96 PST, you wrote: >Also, in this section, however, we should put some words like... > > "It will be suggested (in section 5) that Clients identify Printer objects > using an HTTP type URL. One element of this proposal will be to further > recommend the establishment, through IANA, of a well known port (380 > recommended) for printing via HTTP. The purpose of this well known port > would be to distinguish printing from non-printing content. While any > acceptable HTTP content could be inter-mixed over HTTP well known port 80, > only HTTP printing would be acceptable on port 380. > > The remainder of this draft will define the IPP content for HTTP printing, > including IPP objects, operations, naming and attributes." > >Harry Lewis - IBM Printing Systems > Harry, I brought up this subject with Larry Masinter (who is the IETF HTTP Chair) when I met him last week. He claims that the HTTP does not really care about the port number and that hence it would be no point in using a different number fore the printing protocol. Can somebody else, who is supplying Web servers, verify this? Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 14:47:45 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA14737 for ipp-outgoing; Tue, 19 Nov 1996 14:47:23 -0500 (EST) Message-Id: <9611191749.AA22477@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) Date: Tue, 19 Nov 1996 09:46:17 PST To: ipp@pwg.org From: Tom Hastings Subject: The updated IPP draft is posted for Wed, 11/20 telecon Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Please print the ipp92.pdf file, NOT the .doc, so that we all have the same line numbers for the telcon, Wed, 11/20, 1-3:30pm PST (4-6:30pm EST). (You can get a free pdf reader from Adobe, see their web page). Ignore the ipp92rev.doc and .pdf, they have the revision marks part way through the editing process from ldpa8.doc .pdf. Its in: ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ -rw-r--r-- 1 pwg pwg 130022 Nov 19 07:39 ipp92.PDF Ignoroe: -rw-r--r-- 1 pwg pwg 268288 Nov 19 07:39 ipp92.doc -rw-r--r-- 1 pwg pwg 501760 Nov 19 07:39 ipp92rev.doc -rw-r--r-- 1 pwg pwg 225891 Nov 19 07:48 ipp92rev.PDF Thanks, Tom, Scott, Bob, and Roger From ipp-archive Tue Nov 19 17:22:55 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA15606 for ipp-outgoing; Tue, 19 Nov 1996 17:19:13 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 19 Nov 1996 15:14:12 -0700 From: "Scott A. Isaacson" To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Re: IPP Version 0.92 -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Yes, I expect to have a coherent document by the end of the week. If not, we do have a fallback to just the requirements doc, but we do need to review that as well. These short deadlines have FORCED us (especially me) to focus more than 100% of my time on this which I think is good. If we miss this chance, we might just let it slide out too far. Scott >>> Carl-Uno Manros 11/19/96 12:15pm >>> At 11:34 PM 11/18/96 PST, you wrote: >The section on IPP Operations Using HTTP and how to encode IPP >Operations is brand new, it just got thrown in. Roger did a good job of >pulling it together, but it probably doesn't fit very well in the doc where it >is and it hasn't been reviewe at all. > >Scott A. Isaacson Scott, do you expect that we can have a coherent version by the end of the week to send to the IETF? If not, I suggest that we limit ourselves to sending the Requirements documents at this stage and wait with sending the major document until after the IETF meeting in December. Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Tue Nov 19 18:42:49 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA16097 for ipp-outgoing; Tue, 19 Nov 1996 18:39:19 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 19 Nov 1996 16:38:57 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: 0.92 review comments Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Here are some comments, questions I have about some of the material in IPP Version 0.92: Section 3.4 This indicates one or more Job Templates per Printer. Should this be 0 or more? Section 3.5 and Section 6.2.2.1 3.5 states that a Job object is "identified" by an attribute called job-identifier. 6.2.2.1 indicates that the syntax for job-identifier is "url". Is the job-identifier really "url" or is the job-identifier just some sting that can be used to build a full URL based off of the Printer URL? For example a URL for a certain job might be "http://1.2.3.4/p1/j1". In this case is the job-identifier "http://1.2.3.4/p1/j1" or just "j1"? If job-identifier is "http://1.2.3.4/p1/j1" then why have job-identifier as an attribute of the job object? It would be fairly useless to do the following: ----> POST http://1.2.3.4/p1/j1 http/1.0 Entity header job-identifier: <------ http/1.0 200 "accepted" Entity Header job-identifier: http://1.2.3.4/p1/j1 The same is true for section 6.4.1 printer-name. Is this a name or a URL? Section 4.2.2 and 4.2.3 If there are more than one different URLs for a single Printer and the reason for more than one is to expose different Job Templates, then the Description attribute could be used to help explain the differences in the defaults in each Job Template. There can also be more than one directory entry for the same URL. Tthe reason for this is to expose the same Printer in two different contexts in the directory. Tthe location attribute for each directory entry could be customized to the context of the directory entry. For example, in one context the Location could be informal "Next to Sharon's office" (the directory context itself adds meaning to the phrase next to Sharon's office) and in another context the Location could be more formal, such as "3rd floor, Room 5". Section 5.2.1 This states "job and document attributes" Should this just be Job attributes? Section 5.2.2 Job Id should be a URL coming back to the submitter. Section 5 Many of this operations suggest passing in a list of attributes for which values are being requested? What if the list is empty? Does this mean all attribute values are to be returned, or none? Section 5.5 Should there be an option to request Jobs in: 1) Scheduled order 2) Any order Since we have no operators -- sould Get Jobs return: All Job Ids? Just Job Ids for the requesting end user? Position in the schedule order (my jobs are j1, j2, j3, but their relative positions are #3, #5, #99) Job Ids and a small set of attributes: size, time, position?? I like Roger's suggestion of a count of the total number of jobs pending and processing. Section 6.2.4.1 Since we have a single operation to "submit" a job, will we ever have the state "pre-processing"? Do we want to not have the "printing" state? Section 6.2.4.6 Will we ever have the "documents-needed" reason? job-sheets Since we have job-sheets as only "none" or "defuault", isn't this just a Boolean "TRUE = print the default banner" "FALSE = don't print the default banner" Section 6.4.32 Since maximum-end-user-priority is a Printer object attribute and not a Job Templates attribute, it is hard to acheive the desire effect. Suppose you want some users to have a MAX priority of low and some user to have a MAX of hight. This would require defining TWO Printer object for the same Printer object not just TWO Job Templates for the same Printer Object. However, this doesn't work as a Job Template attribute either - the user just overrides the priority in the Job submission attributes All for now, Scott From ipp-archive Tue Nov 19 20:32:50 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16616 for ipp-outgoing; Tue, 19 Nov 1996 20:28:06 -0500 (EST) Message-Id: Date: Tue, 19 Nov 96 20:28 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: SVRLOC vs. LDAP for printer location services Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Which protocol to employ for the purpose of locating printers will be crucial to the real-world deployment of our implementations. I've scanned both SVRLOC and LDAP. While SVRLOC would probably be easier to use and implement, one can not ignore the avalanche of support that has been building for LDAP over the last few months. Now that Netscape has essentially acquired the original LDAP team (or most of the key players anyway) and has made directory services a top priority at Netscape, it seems that playing in the LDAP arena would have the most long-term potential for us. I intend to stay on top of this issue as time goes on, given that my SENSE activities also deal with directory services. (Our current thinking, though, is that LDAP is way too limited when compared with the SENSE requirements, at least for now. Could be that we use LDAP to locate SENSE servers, though.) Just my penny's worth on this topic. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Tue Nov 19 20:42:50 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA16760 for ipp-outgoing; Tue, 19 Nov 1996 20:41:15 -0500 (EST) From: kcarter@VNET.IBM.COM Message-Id: <199611200141.UAA16755@lists.underscore.com> Date: Tue, 19 Nov 96 19:39:44 CST To: ipp@pwg.org cc: kcarter@VNET.IBM.COM Subject: Service Location Protocol Sender: ipp-owner@pwg.org Precedence: first-class Status: RO To: ipp @ pwg.org cc: From: Keith Carter Date: 11-19-96 01:29:15 PM Subject: Service Location Protocol IPP Team, We do not need to focus on the Service Location Protocol (SLP). IBM will pursue improving the LDAP standard to match capabilities that are supported by SLP but not by LDAP. The most notable example is that SLP allows clients to dynamically locate a directory server which LDAP does not currently support. The reasons for focusing on LDAP over SLP are as follows: - LDAP has garnered wide-spread industry support from Netscape, IBM, Novell, Microsoft and others companies. - LDAP has more robust functionality and a richer API set than SLP. - LDAP explicitly addresses security while SLP does not explicitly address security. Have a super day, Keith From ipp-archive Tue Nov 19 21:12:52 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA16976 for ipp-outgoing; Tue, 19 Nov 1996 21:12:05 -0500 (EST) Message-Id: <2.2.32.19961119221414.0095d8ec@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 14:14:14 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: Draft for IETF IPP WG Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have had a number of suggestions on how to improve on the Draft IETF Charter text that I circulated. By the end of today, I will produce a new version which attempts to take these comments into account, so that we can review a better text in tomorrow's phone conference. Please send further comments today if you want them included in the new version. Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 02:42:56 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17681 for ipp-outgoing; Wed, 20 Nov 1996 02:41:32 -0500 (EST) Message-Id: <9611200148.AA22814@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 17:45:58 PST To: Don Wright From: Tom Hastings Subject: Re: producing flat RFC-ready text files from WORD Cc: "ipp%pwg.org" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 12:43 11/18/96 PST, Don Wright wrote: > >For some reason, I can't get WORD to generate a nice flat >text file with the headers and footers to look like an >internet draft. Anyone got any ideas? > If you setup styles to use only Courier, including in headers and footers, and print to file using a generic line printer driver, it will produce the headers and footers as text. I've been told this works, but I haven't tried it. That is the strategy hope/plan to use to product the IPP draft. I'm planning to use it for the Job Monitoring MIB as well. Each style will have the proper indent, so that WORD will do the line wrap automatically. Good luck. Lets share experiences on this. Thanks, Tom From ipp-archive Wed Nov 20 02:42:57 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17745 for ipp-outgoing; Wed, 20 Nov 1996 02:42:03 -0500 (EST) X-Nvlenv-01Date-Transferred: 19-Nov-1996 13:49:12 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 19-Nov-1996 13:47:20 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 19-Nov-1996 13:49:05 -0500; at x-wb-0311-ms1.xerox Date: Tue, 19 Nov 1996 10:39:55 PST From: Angelo_Caruso@wb.xerox.com (Caruso,Angelo) To: ipp-owner@pwg.org, ipp@pwg.org Subject: RE: IPP 0.92 is in drafts Message-Id: <"DEFD913281262D79@x-wb-0311-ms1.xerox"@-SMF-> Cc: Scott_Isaacson@novell.com ("Scott A. Isaacson") Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The file ipp92.doc in the drafts directory is infected with the concept virus. Angelo Caruso ---------- From: ipp-owner@pwg.org To: ipp@pwg.org Cc: "Scott A. Isaacson" Subject: IPP 0.92 is in drafts Date: Monday, November 18, 1996 11:54PM I forgot to mention that I put v 0.92 in the drafts directory Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Wed Nov 20 02:43:00 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17772 for ipp-outgoing; Wed, 20 Nov 1996 02:42:12 -0500 (EST) Message-Id: <9611200204.AA22822@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 18:01:19 PST To: rdebry@us1.ibm.com From: Tom Hastings Subject: Re: adding to ipp [relates to JMP] Cc: ipp@pwg.org, pwg@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 13:34 11/19/96 PST, rdebry@us1.ibm.com wrote: >I noted that we have no attribute which describes the length of the queue. >One of the main things that I look at when i personally submit print jobs is >how busy the printer is. If a printer is very busy, I find one hat is not so >backed up. What about an attribute called ? I agree. The PWG also agreed to add such an object to the Job Monitoring MIB: jmGeneralCurrentNumberOfJobs. Currently, the spec includes both pending/processing and completed jobs. We should probably have two counters: one for pending/processing and one for completed jobs. One nit, should the pending/processing counter include the currently processing job or not? I think yes, so that an idle printer has a distinct value (0), from one that is processing only one job and there are no more in the queue (1). Tom From ipp-archive Wed Nov 20 02:48:03 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17704 for ipp-outgoing; Wed, 20 Nov 1996 02:41:44 -0500 (EST) Message-Id: <2.2.32.19961120022402.00914aec@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 18:24:02 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Revised Agenda for IETF BOF Meeting Sender: ipp-owner@pwg.org Precedence: first-class Status: RO In light of the suggested changes for the IPP project, I have updated the BOF Agenda. I want us to make sure that we can reach agreement on this in tomorrow's phone conference so that I can pass on the revised version to the IETF. Do we have a volonteer to take notes during the BOF? Carl-Uno ---- Agenda for BOF on Internet Printing Protocol in IETF San Jose Meeting December 12, 1996, 1:00 - 3:00 pm. Introduction (10 mins) History and Requirements (30 mins) - Existing standards for printing - Current user and technology requirements - Proposed Charter for IPP Strawman proposal for the Internet Printing Protocol (30 mins) - Work to date in the Printer Working Group (PWG) - Presentation of the Strawman document Discussion and Resolution of Issues (if possible) (30 mins) - What is the right level of "lightness" for IPP? - Needs to coordinate with other IETF projects? - Choice of Directory service for IPP? - Security Requirements for IPP? Wrap-up (10 mins) - Summary of discussion - List remaining issues to be resolved - Home work assignments - Make recommendation about further progress in IETF Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 02:48:05 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17689 for ipp-outgoing; Wed, 20 Nov 1996 02:41:37 -0500 (EST) Message-Id: <9611200132.AA22792@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 17:30:07 PST To: Don Wright From: Tom Hastings Subject: Re: The updated IPP draft - on NOT using color for revision marks Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Don, I didn't realize that color caused a problem. You are the first to mention it. But I understand how hard it can be to read, same as when I use red color and send it to a blue highlight color printer. On the other hand, those of us that do have highlight color makes reading the revision marks much easier than in all black and white. So how about the following convention for posting files on the ftp server: 1. Always post both a .doc file and a .pdf file with line numbers. (Its probably polite to change the revisions in the .doc file to black and white, but the recipient can too). 2. Always post a .pdf file with no revision marks. 3. Always post a .pdf file with revision marks from the last version, if the changes are not too great. Always make the revision marks be black and white. Go to Tools/Revisions to set to black and white before producing the .pdf file. Add some suffix to the file name, like "rev" or "rv", like Scott did: ipp92.doc, ipp92.pdf, ipp92rev.doc, ipp92rev.pdf 4. Only if you also want to post an additional .pdf file with revision marks can that second revision mark file be with highlight color. Perhaps have a suffix like "rvc". Comments? Tom At 12:09 11/19/96 PST, you wrote: >While we are talking about pet peeves --- please STOP using >color as part of revision marking. Printing the colored text on a >B&W print creates grey text which is hard to read. I'd rather give >up line numbers than have to look at grey text. > >Don > > >To: ipp%pwg.org @ interlock.lexmark.com @ SMTP >cc: (bcc: Don Wright) >From: hastings%cp10.es.xerox.com @ interlock.lexmark.com (Tom Hastings) @ SMTP >Date: 11/19/96 09:46:17 AM >Subject: The updated IPP draft is posted for Wed, 11/20 telecon > >Please print the ipp92.pdf file, NOT the .doc, so that we all have the >same line numbers for the telcon, Wed, 11/20, 1-3:30pm PST (4-6:30pm EST). >(You can get a free pdf reader from Adobe, see their >web page). > >Ignore the ipp92rev.doc and .pdf, they have the revision marks part way >through the editing process from ldpa8.doc .pdf. > >Its in: > > ftp://ftp.pwg.org/pub/pwg/ipp/drafts/ > >-rw-r--r-- 1 pwg pwg 130022 Nov 19 07:39 ipp92.PDF > > >Ignoroe: >-rw-r--r-- 1 pwg pwg 268288 Nov 19 07:39 ipp92.doc >-rw-r--r-- 1 pwg pwg 501760 Nov 19 07:39 ipp92rev.doc >-rw-r--r-- 1 pwg pwg 225891 Nov 19 07:48 ipp92rev.PDF > >Thanks, >Tom, Scott, Bob, and Roger > > > > > From ipp-archive Wed Nov 20 02:48:06 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA17682 for ipp-outgoing; Wed, 20 Nov 1996 02:41:35 -0500 (EST) Message-Id: <2.2.32.19961120020241.00910824@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 18:02:41 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Proposed IETF Charter, Version 2 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi all, thanks for the comments submitted by Bill, Don and Jay. This new version has taken their proposed changes into account, except for the following two points that I did not think were supported by the whole group: 1) Bill suggested that the wording about "authentication etc." was too strong. I believe that the security aspects cannot be underrated when we aim for an Internet standard (as opposed to intranets, where security behind firewalls may be more relaxed). I changed "shall" to "will" if that is considered an improvement? Comments? 2) Jay was uncertain about keeping the formulation about "extensibility paths". We do have this in DPA, and I believe that this is a very important design feature that we need to carry over into the IPP version. Is there really disagreement about this point? What still needs to be done is to add references to the Internet-Draft(s) at the end of the document. As this is a short document, I skipped trying to make line numbers and revision marks. I hope that we can reach agreement on the text tomorrow... Carl-Uno --- (DRAFT 2: 11/19/96) IETF Internet Printing Protocol (ipp) WG Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: TBD Mailing List Information: General Discussion: To Subscribe: Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources, such as printers, and then submit jobs using those resources. The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. The protocol shall support a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). The working group will leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. For location of printers, the working group will leverage existing standards for directories. The working group shall strive to coordinate its activities with other printing-related standards bodies. The new job submission protocol should not strive to preclude any types of output devices (e.g., fax, printer, gateway). Also, the working group shall define extensibility paths so that similar extensions will interoperate and proprietary, dissimilar extensions will never conflict. The Internet Printing Protocol will be designed to make use of Web browsers, HTTP, and LDAP for directory look-ups. The Internet Printing Protocol is intended to replace RFC 1179 'Line Printer Daemon Protocol'. LPR/LPD was designed a long time ago with line printers in mind. It does not fit with current page oriented printing technologies. Deliverables and Milestones: Done Mailing list and archive November 1996 - Submit first set of Internet-Drafts December 1996 - BOF in IETF meeting in San Jose, CA, USA March 1997 - Submit Internet-Drafts April 1997 - Review of specification in IETF meeting in Memphis, TN, USA May 1997 - At least 2 implemented prototypes May 1997 - Submit document(s) to the IESG for Proposed Standard Internet-Drafts: No Current Internet-Drafts Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 07:27:58 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA19025 for ipp-outgoing; Wed, 20 Nov 1996 07:23:48 -0500 (EST) From: manros@mindspring.com Date: Wed, 20 Nov 96 04:05:45 PST Subject: IETF Agenda To: ipp@pwg.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I am probably not the only one that have had problems to retrieve the Agenda for the San Jose meeting from IETF's Web site. By getting up in the middle of the night I have finally managed to retrieve it. Copied below for your convenience. The subjects that we might be interested in are well spread out during the week: HTTP Monday and Tuesday Printer MIB Tuesday HTTP Transport Wednesday IPP (LDPA) Thursday FAX BOF Friday The Agenda can still change, so we need to check for changes. Carl-Uno ------- ****37th IETF: December 9-13, 1996/San Jose, CA**** PLEASE NOTE THE FOLLOWING: 1. NEWCOMER's ORIENTATION: On Sunday, December 8th at 1530 we will be holding an orientation session for Newcomers (Room: Crystal Room) ALL FIRST TIME ATTENDEES ARE ENCOURAGED TO READ RFC 1718 BEFORE ATTENDING THE MEETING. Entitled "The Tao of IETF: A Guide for New Attendees of the Internet Engineering Task Force", this RFC is available by anonymous FTP, although an updated version is available via the WEB. 2. PRE-REGISTRATION and a RECEPTION will be held on Sunday, December 8th from 1700 - 1900 (Room: Regency I & II). 3. A Working Group Chairs Workshop will be held during lunch on Monday, December 9th at 1130. Anyone interested in learning about the role of the working group chair is welcome to attend. Location: TBD. 4. The Agenda below is a DRAFT and therefore subject to frequent changes. We do not advise you use it to determine travel arrangements. -------- FYI..... A reminder that the quality of these meetings (and in particular the Working Group technical *working* sessions) is dependent upon the informed, constructive participation of the individual attendees. Please come prepared. Information on the current status and progress of the individual Working Groups can be obtained in several ways: 1. Working Group objectives and notes from previous sessions are available online (send to ietf-info@ietf.org for retrieval instructions). 2. Working Group objectives and notes from previous meetings are also reproduced in the hardcopy Proceedings (to order, send to proceedings@ietf.org). 3. Agendas and reading lists for Working Group meetings will also be posted to the respective Working Group mailing lists. And when submitted to the Secretariat will be made available via the web. IF YOU HAVE QUESTIONS REGARDING THE SCHEDULING OF A PARTICULAR WORKING GROUP, PLEASE CONTACT THE CHAIR OF THAT GROUP DIRECTLY. A LISTING OF WORKING GROUP MAILING LISTS IS AVAILABLE VIA ANONYMOUS FTP, CD IETF, GET "1wg-summary.txt". LOOKING AHEAD.... Information on future IETF meetings is available from the FTP Directories. Look under filename "0mtg-sites.txt". DRAFT Agenda of the Thirty-Seventh IETF (December 9-13, 1996) As of 11/19/96 MONDAY, December 9, 1996 0800-0900 IETF Registration and Continental Breakfast 0900-1000 Introductions 1000-1130 Morning Sessions APP http HyperText Transfer Protocol WG INT ipcdn IP Over Cable Data Network WG MGT rmonmib Remote Network Monitoring WG MGT snadlc SNA DLC Services MIB WG OPS bmwg Benchmarking Methodology WG OPS rps Routing Policy System WG TSV lsma-bof HOLD TSV rsvp-bof RSVP BOF HOLD Break 1300-1500 Afternoon Sessions I APP drums Detailed Revision/Update of Message Standards WG INT ipngwg IPNG WG MGT trunkmib DS1/DS3 MIB OPS roamops Roaming Operations BOF RTG qosr QoS Routing BOF SEC pkix Public-Key Infrastructure (X.509) WG TSV mmusic Multiparty Multimedia Session Control WG USV uswg User Services 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP ediint Electronic Data Interchange-Internet Integration WG INT ion Internetworking Over NBMA WG MGT ptopomib Physical Topology MIB WG OPS mboned MBONE Deployment WG OPS pier Procedures for Internet/Enterprise Renumbering WG SEC TSV oncrpc ONC Remote Procedure Call WG USV isn Internet School Networking WG 1930-2200 Evening Sessions 1930 APP mhtml MIME Encapsulation of Aggregate HTML Documents WG 2100 APP tn3270e Telnet TN3270 Enhancement BOF INT ipngwg IPNG WG INT svrloc Servoce Location Protocol WG MGT nmarea Network Management Area Open Meeting OPS ire Internet Registry Evolution BOF SEC smime S/MIME BOF TSV rsvp Resource Reservation Setup Protocol WG USV isnII Internet School Networking BOF (Educators) TUESDAY, December 10, 1996 0830-0900 Continental Breakfast 0900-1130 Morning Sessions 0900 APP http HyperText Transfer Protocol WG 1100 APP url-bof Uniform Resource Locators BOF INT ipcdn IP over Cable Data Network WG MGT atommib AToM MIB WG MGT ptopomib Physical Topology MIB WG OPS ippm IP Performance Metrics RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC cat Common Authentication Technology WG TSV mmusic Multiparty Multimedia Session Control WG Break 1300-1500 Afternoon Sessions I APP calsch Calendaring and Scheduling WG INT pppext Point-to-Point Protocol Extensions WG MGT printmib Printer MIB WG MGT rmonmib Remote Network Monitoring WG OPS icp Internet Cache Protocol BOF OPS mboned MBONE Deployment WG RTG udlr UniDirectional Link Routing BOF SEC pkix Public-Key Infrastructure (X.509) WG 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP ftpext Extensions to FTP WG INT ion Internetworking Over NBMA WG MGT nmarea Network Management Area Open Meeting OPS newdom New Top Level Domains OPS 6bone IPv6 Backbone BOF RTG rip Routing Information Protocol WG SEC ipsec IP Security Protocol WG TSV avt Audio/Video Transport WG WEDNESDAY, December 11, 1996 0830-0900 Continental Breakfast 0900-1130 Morning Sessions APP ids Integrated Directory Services APP webdav WWW Distributed Authoring and Versioning BOF INT pktway PacketWay WG INT vtp Virtual Tunneling Protocol BOF MGT agentx SNMP Agent Extensibility WG OPS rtfm Realtime Traffic Flow Measurement WG RTG tagsw Tag Switching BOF SEC dnssec Domain Name System Security WG Break 1300-1500 Afternoon Sessions I APP find Common Indexing Protocol WG INT dhc Dynamic Host Configuration WG MGT applmib Application MIB WG MGT snadlc SNA DLC Services MIB WG OPS rps Routing Policy System WG RTG ospf Open Shortest Path First IGP WG SEC spki Simple Public Key Infrastructure BOF 1300 APP/TSV http bof HTTP Transport BOF (1300-1400) HOLD 1400 TSV relmult HOLD (1400-1500) 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP asid Access, Searching and Indexing of Directories WG APP nntp Network News Transport Protocol WG HOLD INT pppext Point-to-Point Protocol Extensions WG MGT disman Distributed Management WG RTG idmr Inter-Domain Multicast Routing WG SEC cat Common Authentication Technology WG TSV tcpimp HOLD USV run Responsible Use of the Network WG 1930-2200 Evening Sessions APP acap Application Configuration Access Protocol WG 1930 GEN iab Internet Architecture Board Open Meeting (1930-2100) 2100 GEN iahc International Ad Hoc Coalition BOF (2100-2200) INT dhc Dynamic Host Configuration WG MGT disman Distributed Management WG MGT frnetmib Frame Relay Service MIB WG OPS rwhois RWhois Operational Development WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG TSV avt Audio/Video Transport WG 2230 Late Night Session PGP Key Signing Party THURSDAY, December 12, 1996 0830-0900 Continental Breakfast 0900-1130 Morning Sessions APP urn Uniform Resource Names WG MGT atommib AToM MIB WG OPS rtfm/ippm Realtime Traffic Flow Measurement/IP Performance Metrics RTG idmr Inter-Domain Multicast Routing WG SEC otp One Time Password Authentication WG TSV nfs-bof NFS BOF USV ssh Site Security Handbook WG Break 1300-1500 Afternoon Sessions I APP ldpa Lightweight Document Printing Appplication BOF INT ipngwg IPNG WG MGT applmib Application MIB WG RTG idr Inter-Domain Routing WG SEC saag Open Security Area Directorate Meeting BOF TSV issll Integrated Services over Specific Link Layers WG USV harts Humanities and Arts WG 1500-1530 Break (Refreshments provided) 1530-1700 Presentations o NSF Routing Arbiter Project Ramesh Govindan (USC/Information Sciences Institute) Brian Renaud (Merit Network Inc.) o TCP Plotting Method Tim Shepard (BBN) o Next Generation Internet Initiative Tom Kahil o xDSL Aspects and Technologies Kim Maxwell (chair of ADSL Forum) 1800-1900 Open Plenary and IESG FRIDAY, December 13, 1996 0830-0900 Continental Breakfast 0900-1130 Morning Sessions APP faxbof Fax BOF INT/SEC dnsind/dnssec DNS IXFR, Notification and Dynamic Update Joint with Domain Name System Security WG GEN newgen Next Generation Internet Initiative BOF MGT frnetmib Frame Relay Service MIB WG OPS ngtrans New Generation Transition WG SEC pgp/mime MIME Security with Pretty Good Privacy BOF TSV issll Integrated Services over Specific Link Layers WG Key to Abbreviations APP Applications Harald Alvestrand/UNINETT and Keith Moore/UTK GEN General Interest Fred Baker/Cisco Systems INT Internet Frank Kastenholz/FTP Software and Jeffrey Burgan/Bay Networks MGT Network Management Deirdre Kostick/AT&T OPS Operational Requirements Scott Bradner/Harvard and Michael O'Dell/UUNET Technologies RTG Routing Joel Halpern/Newbridge Networks SEC Security Jeff Schiller/MIT TSV Transport Allison Mankin/ISI and Allyn Romanow/Sun Microsystems USV User Services Joyce K. Reynolds/ISI From ipp-archive Wed Nov 20 07:47:58 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA19211 for ipp-outgoing; Wed, 20 Nov 1996 07:46:54 -0500 (EST) Message-Id: <199611201247.AA20792@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 20 Nov 96 7:45:15 EST Subject: ipp92.doc - Concept Virus Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have cleaned ipp92.doc and removed the concept virus. I have replaced the copy on the ftp server with a clean one. Additionally, I have posted a copy of scanprot.doc which you can use on your system to clean up the effects of the virus and scan your .doc files to see if any others are infected. Scanprot.dot can be found in: ftp://ftp.pwg.org/pub/pwg/ipp/tools/scanprot.dot ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Wed Nov 20 11:01:53 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19931 for ipp-outgoing; Wed, 20 Nov 1996 10:57:00 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 20 Nov 1996 08:56:04 -0700 From: Scott Isaacson To: hastings@cp10.es.xerox.com, don@lexmark.com Cc: ipp@pwg.org Subject: Re: producing flat RFC-ready text files from WORD -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom, I have tried this several times. Bob H. claims that it worked for him, but I still can't get it to work for the IPP document. The resulting ASCII text file does have all of the "text" and the headers and footers, but it has some other "control" characters that do not make it look like the pure printable text format I have seen for other I-Ds and RFCs. Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> Tom Hastings 11/19/96 06:45pm >>> At 12:43 11/18/96 PST, Don Wright wrote: > >For some reason, I can't get WORD to generate a nice flat >text file with the headers and footers to look like an >internet draft. Anyone got any ideas? > If you setup styles to use only Courier, including in headers and footers, and print to file using a generic line printer driver, it will produce the headers and footers as text. I've been told this works, but I haven't tried it. That is the strategy hope/plan to use to product the IPP draft. I'm planning to use it for the Job Monitoring MIB as well. Each style will have the proper indent, so that WORD will do the line wrap automatically. Good luck. Lets share experiences on this. Thanks, Tom From ipp-archive Wed Nov 20 11:06:55 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20210 for ipp-outgoing; Wed, 20 Nov 1996 11:05:25 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 20 Nov 1996 09:05:24 -0700 From: Scott Isaacson To: cmanros@cp10.es.xerox.com, ipp@pwg.org Subject: Proposed IETF Charter, Version 2 -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Thanks Carl-Uno, the charter looks good. There was an earlier concern about prototypes. Not contractually obligating Novell to anything, I can reasonably expect that we will be working on not only prototypes of this but actually folding it back into our products. At our October press release we stated that it is our intent to move our products to implement whatever standard emerges from this process. Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Wed Nov 20 11:06:55 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20310 for ipp-outgoing; Wed, 20 Nov 1996 11:06:08 -0500 (EST) Mime-Version: 1.0 Date: Wed, 20 Nov 1996 11:08:40 -0500 Message-Id: <00009199.1337@digprod.com> From: bwagner@digprod.com (Bill Wagner) Subject: Re: Proposed IETF Charter, Version 2 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: first-class Status: RO Carl-Uno, I think it is looking pretty good. Two minor "wordsmith" items: In the second paragraph: "The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. " I suggest making the structure more parallel: "The goal of this working group is to define a new application level distributed printing protocol and to define naming and service registration attributes for printing." In the fifth paragraph, "The new job submission protocol should not strive to preclude any types of output devices (e.g., fax, printer, gateway)." I suggest that what was intended was: "The working group will strive to ensure that the new job submission protocol does not preclude the use of any type of output device (e.g., fax, printer, gateway)." Regards, Bill Wagner, DPI From ipp-archive Wed Nov 20 11:57:05 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA20678 for ipp-outgoing; Wed, 20 Nov 1996 11:56:13 -0500 (EST) Message-ID: <3293385D.4487EB71@underscore.com> Date: Wed, 20 Nov 1996 11:57:01 -0500 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: pwg@pwg.org, ipp@pwg.org Subject: PWG and IPP mailing list subject lines Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO When I reset the IPP mailing list after the "glitch", I dropped the majordomo feature that can prepend a string to message subject lines (since one subscriber had complained). Now I've received another request to restore the feature (which I like since it makes it easy to scan and group lists of incoming messages). Unless people object by this Friday, I will restore the feature(with no disruption to the lists). This time I'll be using "PWG>" and "IPP>" as the prefixes to better separate the prefix from the text of the subject line. So you'll see subject lines like: 1st message= Subject: PWG> Sample subject line 1st reply= Subject: Re: PWG> Sample subject line 2nd reply= Subject: Re: PWG> Sample subject line What say ye? /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 Wed Nov 20 14:16:56 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21505 for ipp-outgoing; Wed, 20 Nov 1996 14:14:16 -0500 (EST) Message-Id: <2.2.32.19961120184440.008fe6e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 10:44:40 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Report from WEBDAV Meeting Sender: ipp-owner@pwg.org Precedence: first-class Status: RO On invitation from Larry Masinter at PARC, I attended a meeting of the WG on Distributed Authoring and Versioning on the World Wide Web (WEBDAV). This group is primarily working on various issues associated with document repositories. It turned out that this group was grappling with some of the same issues as we will face in the Internet Printing Protocol (IPP) project. In particular, the following areas seem to be of common interest: - Use of Attributes - Need for a Search/Lookup capability - Need for a Notification service - Use of current HTTP features vs. new extensions WEBDAV is currently seeking to become a WG in the IETF, and is also trying to become a recognized WG of the W3C. A WEBDAV meeting will be held during the upcoming IETF meeting in San Jose. This is the kind of group in which the "real players", Microsoft, Netscape, and Novell are active. I held a short verbal presentation about the current plans for the IPP project in IETF. Several participants expressed interest to start following the activities of the IPP project. Below follows a write-up from the meeting by the chair - Jim Whitehead from UC Irvine. Carl-Uno Manros -------- WEBDAV Palo Alto meeting overview >From: Jim Whitehead >Sender: w3c-dist-auth-request@w3.org >Resent-Sender: w3c-dist-auth-request@w3.org > >The working group on Distributed Authoring and Versioning on the World Wide >Web (WEBDAV) held a meeting at Xerox PARC on November 14-15, 1996, in Palo >Alto, California. There were 28 attendees from the following >organizations: America Online, AmerInd, Canon Info. Sys., Continuus, Dept. >of Veterans Affairs, Microsoft, Mortice Kern Systems, Netscape, Novell, >NTT, Pure Atria, Saros/Filenet, SoftQuad, U.C. Irvine, Web Tools Int'l, >World Wide Web Consortium, and Xerox. The working group thanks Larry >Masinter, Xerox PARC for providing food and meeting space as the host of >this meeting. Further thanks go to Keith Dawson, Pure Atria, for his >meeting notes. > >In the following message, a dash "-" denotes a meeting date, an asterisk >"*" represents an item of consensus, and and equals "=" denotes an action >item. > >This message should not be construed to be the official minutes of the >meeting (these are still under preparation). However, this document will >likely form the core of the official minutes of the meeting, and as such, >if you find any errors, or misrepresentation of the events which took >place, please let me (Jim Whitehead, ejw@ics.uci.edu) know so the error >will not propagate into the official minutes. > >UPCOMING MEETINGS > >- The next meeting of the working group will be at the WEBDAV BOF at the >San Jose IETF meeting. The WEBDAV BOF is currently scheduled for >Wednesday, December 11, 1996, from 9:30 to 11:30AM. >- The following meeting will be held at U.C. Irvine, in late January 1997. >The WG agreed upon the dates January 23-24, but due to a UCI scheduling >conflict (the Conference on Software Process Improvement, CoSPI), these >dates are not open. I will be polling the working group soon for new >dates. >- The W3C Symposium, Distributed Authoring: Present and Future, will be >held at the Sunnyvale Hilton Inn, December 4-5, 1996. For more details, >consult: http://www.w3.org/pub/WWW/Authoring961001/Call.html. > >Day 1 (Thursday, November 14) > >The meeting began with a presentation by Kenji Ota, NTT on the NTT >versioning draft. This was followed by a presentation by Yaron Goland, >Microsoft, on the major design issues facing this group, as reflected in >v0.2 of the Goland/Whitehead draft. > >Two issues were primarily considered for the remainder of the day, POST vs. >methods, and attributes. > >POST vs. METHODS: > >The discussion on POST vs. methods centered on whether the DAV >functionality should be specified by creating a special purpose MIME type >which is then sent to a server using the HTTP POST method, or whether new >HTTP methods should be created for this. In the POST approach, the MIME >type would specify the functionality (e.g., application/copy), whereas the >method approach would use a new method (e.g., COPY). Within the methods >approach, there were two choices for where to place request parameters: a) >in new, method-specific headers, or b) in the body of the request message. > >* The group reached rough consensus that new DAV functionality should be >specified with new HTTP methods, with request parameters in the message >body. However, this was subject to the caveat that existing HTTP/1.1 >headers should be used where appropriate and consistent with existing >meaning and usage. Also, this design choice was not meant to preclude the >definition of new headers, if they are the best design choice. > >ATTRIBUTES: > >Discussion of attributes spanned two days. Despite several hours of >discussion, the working group did not reach consensus on attribute >functionality. Key design issues for attributes are: > >o naming (e.g. URL munging?) >o search/lookup >o attribute discovery >o one round-trip lookup of an attribute's value >o is an attribute's value a resource, a pointer to a resource, or part of a >resource? >o should attributes be versioned individually, or with the resource they >describe? > >One common thread of discussion centered around how much indirection should >be provided when looking up attributes. One position held that one round >trip lookup of an attribute's value was necessary for efficiency, which >argues for a lookup directly returning the attribute's value. Others held >that, for generality, attributes could hold a URL, which would point to the >resource containing the attribute's value. Yet another proposal suggested >that a resource would contain a LINK header pointing to an "attributes" >resource, which groups all attribute/value pairs. A URL munge on the URL >of the "attributes" resource (e.g., http://foo.bar.com/attrs?Author) would >return the value of the attribute (this approach was called, "a license to >munge," since the >server provides the URL and thus guarantees that it can be munged, much >like imagemap URLs, without concern for collision with other valid URLs). > >However, there were some points of commonality amid the discussion. > >* Trying to develop a set of core attributes, such as the Dublin Core, was >considered to be a bad idea. Instead, a means should be provided for using >existing attribute sets, and for discovering which attribute sets are being >used to describe a resource. > >* The LDAP search syntax (RFC 1959) is worth investigating for use as an >attribute search syntax. > >= Due to the lack of consensus, the group decided to solicit drafts >describing attribute functionality for the Web. The deadline for >submission of attribute drafts to the working group list is Nov. 26. >Authors of drafts are encouraged to submit their drafts as Internet Drafts >so they may be considered at the San Jose IETF meeting. > >NETSCAPE DRAFT > >During the day, Jim Cunningham and Asad Faizi circulated paper copies to >all attendees of their draft on how to perform distributed authoring and >versioning functionality, titled "Distributed Authoring and Versioning >Protocol." The draft circulated was version 0.1. The draft describes how >to implement the Distributed Authoring and Versioning requirements using >methods. It is currently unclear how open Netscape will be concerning this >draft. Asad Faizi will be working with Yaron Goland, Jim Whitehead, and >Del Jensen to develop subsequent working group drafts. > >Day 2 (Friday, November 15) > >The second day began with a discussion of the sponsorship and activities of >this working group. > >* The group unanimously decided to pursue a path of joint IETF and W3C >sponsorship. >= Jim Whitehead agreed to revise and submit the WG Charter to the IETF >Application Area Directors in hopes that the WEBDAV group could be an >official IETF working group by the San Jose IETF meeting. > >* The group agreed that all current drafts of the working group should be >submitted as Internet Drafts by the IETF deadline, November 26. > >= The group continued to feel that further development and refinement of >the scenarios document was worthwhile, as a sanity check on our final >specification, as a good way for people to understand our work, and to >understand the rationale for our requirements. The working group was >instructed to provide feedback to Ora Lassila on the >scenarios document. Ora should submit the scenarios document by the Nov. >26 IETF deadline. > >= The group agreed that merging the Distributed Authoring (Whitehead) and >the Versioning (Durand, Vitali) requirements documents was a good idea. >This way the group will produce one DAV spec., and one DAV requirements >document. Durand, Vitali, and Whitehead will work on producing this merged >document. > >CONTAINERS > >The following issues concerning containers were discussed: > >o Should a container just be a resource with no special semantics, or >should a container resource have special container-specific semantics (e.g. >recursion through hierarchy levels). The group tended to think that >container-specific semantics would be the most useful, but also more >complicated. >o It was discovered that there are situations where it is useful to state >whether you are operating on a resource as a resource, or on a resource as >a container. For example, if a container is a collection of pointers to >resources, then making a copy of the container is similar to making a >number of symbolic links (soft links) in a filesystem. However, copying a >container with container semantics could cause a recursive copy of all the >elements of the container, making duplicates of all resources (hard links). >This led to a discussion of where the "switch" should be placed to specify >what kind of semantics are desired (opaque resource vs. container >resource). It was noted that filesystems have dealt with this issue. >o The WebMap specification was discussed as a potential format for >container resources. Unfortunately, the latest WebMap specification was >not available for thoughful consideration by the working group prior to the >meeting. > >= Like attributes, the working group is encouraged to submit drafts on >containers to the working group by the November 26, IETF deadline. > >VERSIONING > >There was a long discussion on versioning. Members of the working group >expressed frustration that the v0.2 Goland/Whitehead draft did not specify >versioning capability in sufficient detail to evaluate it. Some issues: > >o The terms, "checkout" and "checkin" as defined in the v0.2 spec. overload >the commonly understood meaning for these terms. It was agreed that some >other term (e.g., edit notification) would be used. >o Since different versioning systems have different definitions of the >meaning of checkout and checkin (e.g., for checkout: edit notification plus >write lock (RCS, SCCS) or edit notification only, no lock (CVS)), the >server should be able to implement whatever versioning style it wishes, and >the client must adapt to it. This raises the issue of how to specify the >checkout style used on a server in a manner the client can understand. >o There seem to be two main points of difference between versioning styles: >write lock vs. no lock, and object create on checkout or checkin. All >versioning styles appear to record the owner of the checkout (i.e., a >notification of intention to edit). >o There was some discussion concerning whether versions of a resource were >resources, or were representations of a resource. The group tended towards >thinking that versions of a resource were themselves resources. Delta >storage mechanisms are not a major concern for this group since they can be >considered a server implementation issue. > >There was one important point of consensus: > >* All versions of a resource should be addressable (i.e., have a unique URL) > >RELATIONS > >There was a short discussion of the relationship model in the v0.2 spec. >The group agreed that adding peer fields to LINK style relationships was >worth investigating further. There was some concern that replicating the >URL in the (rtoken, URL) peer pairs was not space efficient. > >REPRESENTATION/MANIPULATION > >There was a discussion about the interaction between variants of a >resource, and versions of a resource. The group came to the conclusion >that containers, content negotiation and versions are all orthogonal. > >* The group came to the consensus that variants can be versioned. > >* There was also some discussion of whether method parameters could be >subject to content negotiation. HTTP does not allow the Accept* request >headers to be used for selection of the target of an action (method); they >can only be used for selection of the content of the response message after >the action is taken. As a result, the group came to consensus that no use >of content negotiation should be allowed on the parameters of a method >invocation. > >There was also some discussion about the utility of allowing remote editing >of content negotiation information. However, this was agreed to be pushed >off into the next round of DAV activity. > >RELATED DISCUSSION > >Over lunch, Carl-Uno Manros discussed the work he is doing on the PWG, >Internet Printing Project (ipp). I'll leave it to Carl-Uno to summarize >this discussion. > >At the end of the day, Mike Spreitzer led a discussion on four issues, >which helped establish the boundaries of what should be considered by the >WebDAV working group: > >o Database: A more direct mapping of database concepts into the DAV >protocol. Consensus: out of scope. >o Proxy: Should DAV capabilities can accessible from proxies and the origin >server, or only the origin server. Consensus: minimal proxy support, most >operations must go to origin server. >o Disconnected operation: To what degree should the DAV protocol consider >disconnected editing and operation. Consensus: much disconnected operation >is already possible, and more can be enabled by allowing for queuing of >requests, but the DAV group will assume that such queueing only takes >place >within the client and not within external proxies. >o Distributed filesystem: it might be a good idea to consider the related >work on distributed filesystems. Some related systems are: Coda, CMU; >Ficus, UCLA; and Bayou, PARC. > >- Jim Whitehead ---- Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 14:36:56 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21672 for ipp-outgoing; Wed, 20 Nov 1996 14:33:24 -0500 (EST) Message-Id: <2.2.32.19961120193127.009299a8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 11:31:27 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: PING Confirmations for IETF BOF Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi, This is the current list of BOF participants: Roger deBry IBM Tom Hastings Xerox Robert Herriot Sun Scott Isaacson Novell Raymond Lutz Cognisys Carl-Uno Manros Xerox Jay Martin Underscore Bill Wagner DPI, Osicom Rob Whittle Novell Don Wright Lexmark It is still shorter than I had hoped for. Did I miss anybody? Any more planning to participate who have not yet answered the PING? Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 14:41:56 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA21842 for ipp-outgoing; Wed, 20 Nov 1996 14:41:40 -0500 (EST) Message-ID: <32935CD9.7C37@sharplabs.com> Date: Wed, 20 Nov 1996 11:32:41 -0800 From: Randy Turner Reply-To: rturner@sharplabs.com Organization: Sharp Labs of America X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Carl-Uno Manros CC: ipp@pwg.org Subject: Re: PING Confirmations for IETF BOF References: <2.2.32.19961120193127.009299a8@garfield> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I will be at the IETF all week and will also attend the BOF. Randy Randy Turner Network Architect Sharp Laboratories of America 5750 NW Pacific Rim Blvd Camas, WA 98607 rturner@sharplabs.com From ipp-archive Wed Nov 20 15:36:57 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22302 for ipp-outgoing; Wed, 20 Nov 1996 15:33:08 -0500 (EST) From: mabry@rd.qms.com Date: Wed, 20 Nov 96 14:29:03 CST Message-Id: <9610208485.AA848528943@rdccout.rd.qms.com> To: ipp@pwg.org, Carl-Uno Manros Subject: Re: PING Confirmations for IETF BOF Sender: ipp-owner@pwg.org Precedence: first-class Status: RO QMS will attend, hopefully it will be myself, however it could be someone else if I cannot make arrangements. Am I correct that the 12th is the main day that attendance is needed/necessary? Mabry Dozier QMS Inc. mabry@rd.qms.com ______________________________ Reply Separator _________________________________ Subject: PING Confirmations for IETF BOF Author: Carl-Uno Manros at smtplink-rd Date: 11/20/96 1:33 PM Hi, This is the current list of BOF participants: Roger deBry IBM Tom Hastings Xerox Robert Herriot Sun Scott Isaacson Novell Raymond Lutz Cognisys Carl-Uno Manros Xerox Jay Martin Underscore Bill Wagner DPI, Osicom Rob Whittle Novell Don Wright Lexmark It is still shorter than I had hoped for. Did I miss anybody? Any more planning to participate who have not yet answered the PING? Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 15:41:57 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA22475 for ipp-outgoing; Wed, 20 Nov 1996 15:41:23 -0500 (EST) Message-Id: <9611202035.AA23287@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 2 (High) Date: Wed, 20 Nov 1996 12:32:20 PST To: m.kirk@xopen.org From: Tom Hastings Subject: Can I distribute the X/Open PSIS/XDPA Appendix on LPD Extensions? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Martin, I've had a long standing action item from the IETF Printer Working Group (PWG) to distribute the entire PSIS standard in its current form to the PWG. While I still like to get your permission to distribute the entire PSIS/XDPA document, one particularly important part of the document is the Appendix that show how the vendors (DEC, HP, IBM, SCO, Xerox) have extended LPD in incompatible ways. Can I distribute that PSIS/XDPA appendix to the PWG for its Internet Printing Protocol (IPP) standards project? Thanks, Tom From ipp-archive Wed Nov 20 17:51:58 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22743 for ipp-outgoing; Wed, 20 Nov 1996 17:51:12 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <862563E8:007B46A5.00@aussmtp3.austin.ibm.com> Date: Tue, 19 Nov 1996 13:29:15 -0500 Subject: Service Location Protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO IPP Team, We do not need to focus on the Service Location Protocol (SLP). IBM will pursue improving the LDAP standard to match capabilities that are supported by SLP but not by LDAP. The most notable example is that SLP allows clients to dynamically locate a directory server which LDAP does not currently support. The reasons for focusing on LDAP over SLP are as follows: - LDAP has garnered wide-spread industry support from Netscape, IBM, Novell, Microsoft and others companies. - LDAP has more robust functionality and a richer API set than SLP. - LDAP explicitly addresses security while SLP does not explicitly address security. Have a super day, Keith From ipp-archive Wed Nov 20 17:56:57 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA22877 for ipp-outgoing; Wed, 20 Nov 1996 17:52:22 -0500 (EST) From: Keith_Carter@aussmtp.austin.ibm.com X-Lotus-FromDomain: AUSNOTES To: ipp@pwg.org Message-ID: <862563E8:007B46D1.00@aussmtp3.austin.ibm.com> Date: Tue, 19 Nov 1996 13:29:15 -0500 Subject: Service Location Protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipp-owner@pwg.org Precedence: first-class Status: RO IPP Team, We do not need to focus on the Service Location Protocol (SLP). IBM will pursue improving the LDAP standard to match capabilities that are supported by SLP but not by LDAP. The most notable example is that SLP allows clients to dynamically locate a directory server which LDAP does not currently support. The reasons for focusing on LDAP over SLP are as follows: - LDAP has garnered wide-spread industry support from Netscape, IBM, Novell, Microsoft and others companies. - LDAP has more robust functionality and a richer API set than SLP. - LDAP explicitly addresses security while SLP does not explicitly address security. Have a super day, Keith From ipp-archive Wed Nov 20 19:11:58 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23095 for ipp-outgoing; Wed, 20 Nov 1996 19:09:18 -0500 (EST) Message-Id: <2.2.32.19961121000746.0094ac28@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 16:07:46 PST To: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu From: Carl-Uno Manros Subject: Proposed Charter for Internet Printing Protocol WG Cc: ipp@pwg.org, xerox-ldpa@cp10.es.xerox.com Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Harald and Keith, We have now refined the earlier PWG Charter into a Proposed Charter for a WG in the IETF, and would like your feedback if this is now OK. Note that we recommend changing the title of the group to IPP, rather than LDPA as previously suggested. I have also included a revised agenda for the BOF meeting (including a title change). Is there still a chance that we can still get the WG formed in time for the San Jose meeting (our preference) or did we miss that boat? If so, can the BOF be changed to become a WG meeting? If we become a WG in time for the IETF meeting, the agenda needs some further updating. For that reason I have not yet sent the revision to the IETF. We are still polishing the texts on the two Internet-Drafts mentioned in the Charter Draft. They will be finalized and sent to the IETF over the week-end. I have about 15 people so far that has confirmed to me that they will show up in San Jose for this subject. I have no doubt that we will get quite a few more that I do not know about yet. This subject is certainly moving ahead. Greetings, Carl-Uno ----- IETF Internet Printing Protocol (ipp) WG Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: TBD Mailing List Information: General Discussion: To Subscribe: Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources, such as printers, and then submit jobs using those resources. The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. The protocol shall support a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). The working group will leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. For location of printers, the working group will leverage existing standards for directories. The working group shall strive to coordinate its activities with other printing-related standards bodies. The new job submission protocol should strive not to preclude any types of output devices (e.g., fax, printer, gateway). Also, the working group will define extensibility paths to maximize interoperability and minimize conflict. The Internet Printing Protocol will be designed to make use of Web browsers, HTTP, and LDAP for directory look-ups. The Internet Printing Protocol is intended to supplant RFC 1179 'Line Printer Daemon Protocol' as the preferred printing protocol. LPR/LPD was designed a long time ago with line printers in mind and does not fit with current needs. Deliverables and Milestones: Done - Mailing list and archive November 1996 - Submit first set of Internet-Drafts December 1996 - IETF meeting in San Jose, CA, USA March 1997 - Submit Internet-Drafts April 1997 - Review of specification in IETF meeting in Memphis, TN, USA May 1997 - At least 2 implemented prototypes May 1997 - Submit document(s) to the IESG for Proposed Standard Internet-Drafts: IPP-requirements (title TBD) IPP-draft (title TBD) --------- Agenda for BOF on Internet Printing Protocol in IETF San Jose Meeting December 12, 1996, 1:00 - 3:00 pm. Introduction (10 mins) History and Requirements (30 mins) - Existing standards for printing - Current user and technology requirements - Proposed Charter for IPP Proposal for the Internet Printing Protocol (30 mins) - Work to date in the Printer Working Group (PWG) - Presentation of the IPP draft document Discussion and Resolution of Issues (if possible) (30 mins) - Needs to coordinate with other IETF projects? - Security Requirements for IPP? - Other issues? Wrap-up (10 mins) - Summary of discussion - List remaining issues to be resolved - Home work assignments - Make recommendation about further progress in IETF ------ Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 19:46:58 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA23272 for ipp-outgoing; Wed, 20 Nov 1996 19:42:31 -0500 (EST) Message-Id: <9611210043.AA23437@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 16:40:39 PST To: Scott_Isaacson@novell.com (Scott Isaacson) From: Tom Hastings Subject: IPP formatting problem: 8-bit characters present and how to remove them Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott, There are a number of 8-bit characters present in ipp92.doc which IETF plain text rules don't allow in the IPP spec. For example, there are a number of em-dash characters. Also left and right single quotes. Maybe double quotes too. You can change them all by making sure the Tools/Auto Correct has smart quotes turned off. Then do a Replace All of " with " i.e., replace the same character with the same character and it finds all double quotes and replaces them with neutral double quotes. Same for single quote ('). And same for hyphen (-). Keep the Auto Correct with smart quotes turned off for further editing. Tom From ipp-archive Wed Nov 20 20:42:07 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA23444 for ipp-outgoing; Wed, 20 Nov 1996 20:38:23 -0500 (EST) Message-Id: <2.2.32.19961121013646.00934568@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 17:36:46 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: PING Confirmations for IETF BOF Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Yes, the IPP BOF is on December 12, 1:00 - 3:00 pm. Carl-Uno At 12:29 PM 11/20/96 PST, you wrote: > > > QMS will attend, hopefully it will be myself, however it could be > someone else if I cannot make arrangements. > > Am I correct that the 12th is the main day that attendance is > needed/necessary? > > > Mabry Dozier > QMS Inc. > mabry@rd.qms.com > > > > >______________________________ Reply Separator _________________________________ >Subject: PING Confirmations for IETF BOF >Author: Carl-Uno Manros at smtplink-rd >Date: 11/20/96 1:33 PM > > >Hi, > >This is the current list of BOF participants: > >Roger deBry IBM >Tom Hastings Xerox >Robert Herriot Sun >Scott Isaacson Novell >Raymond Lutz Cognisys >Carl-Uno Manros Xerox >Jay Martin Underscore >Bill Wagner DPI, Osicom >Rob Whittle Novell >Don Wright Lexmark > >It is still shorter than I had hoped for. Did I miss anybody? Any more >planning to participate who have not yet answered the PING? > >Carl-Uno > > >Carl-Uno Manros >Xerox Corporation >701 S. Aviation Blvd. >M/S: ESAE-231 >El Segundo, CA 90245, USA >E-mail: manros@cp10.es.xerox.com > > > Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 20 22:16:59 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA23674 for ipp-outgoing; Wed, 20 Nov 1996 22:12:03 -0500 (EST) X-Nvlenv-01Date-Transferred: 20-Nov-1996 16:04:09 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 20-Nov-1996 16:00:44 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 20-Nov-1996 16:03:57 -0500; at x-wb-0311-ms1.xerox Date: Wed, 20 Nov 1996 12:54:04 PST From: Angelo_Caruso@wb.xerox.com (Caruso,Angelo) To: ipp@pwg.org Subject: RE: Directory Entry Schema Message-Id: <"D771933281262D79@x-wb-0311-ms1.xerox"@-SMF-> Cc: Scott_Isaacson@novell.com ("Scott A. Isaacson") Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott, In my opinion subjective attributes are not very useful. Print quality, for example, is so subjective that 'high', 'medium', and 'low' just don't cut it. Also, a user's perception of 'high' or 'low' print quality evolves with the state of the art. Why not specify objective attributes like resolution, process (e.g. ink-jet, laser, etc.), color capability (e.g. monchrome, full process color, etc.)? Cost is also highly subjective (one man gathers what another man spills). Marketers are constantly manipulating cost-per-page estimates in order to position a product more competitively (some include only toner, some include other supplies as well). Costs also evolve very rapidly over time. Who would make these subjective judgements? My two cents per page :) Angelo Caruso Xerox Corp. ---------- From: ipp-owner@pwg.org To: ipp@pwg.org Cc: "Scott A. Isaacson" Subject: Directory Entry Schema Date: Monday, November 18, 1996 7:18PM Keith Carter and I met and we want to run the following issues by the team: We want to have a Location attribute. We propose that this should be a " a free form string that can contain any site specific location information." How should filtered searches work on values of this attribute? We want to introduce a new attribute callled Print Quality. "This indicates a somewhat subjective evaluation of the overall printing quality: "high", "medium", or "low" " ISSUE: Does this subsume the need for Resolution and Speed? We want to introduce a new attribute called Cost. "This indicates a somewhat subjective evaluation of the overall cost of printing at this printer: "high", "medium", or "low". " ISSUE: Is this a good thing or not? We propose a Fonts Supported attribute which is the same as the fonts-supported attribute in the Printer object. ISSUE: Do you agree that this should be in the directory entry. Some studies have shown that users want to search for printers based on this attribute. If we keep Maximum Speed should it be moved to "high, med low"?? We propose a P1284 Device ID not a plug and play Id -- the plug and play id can be created from this. ISSUE: Does this subsume the need for Make, Model, and Type?? ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Thu Nov 21 09:12:07 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA24250 for ipp-outgoing; Thu, 21 Nov 1996 09:07:56 -0500 (EST) Date: Thu, 21 Nov 96 09:08:24 EST From: Robert McComiskie Message-Id: <9610218485.AA848596329@smtplink.xionics.com> To: ipp@pwg.org Subject: Test Message Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have not seen any activity here since joining. Is something amiss? Bob. /********************************************************************* ** Bob McComiskie Voice: 617-229-7021 ** ** Senior Product Manager Fax: 617-229-7120 ** ** Xionics Document Technologies, Inc. ** ** 70 Blanchard Road rmccomiskie@xionics.com ** ** Burlington, MA 01803 USA http://www.xionics.com ** *********************************************************************/ From ipp-archive Thu Nov 21 10:07:08 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24510 for ipp-outgoing; Thu, 21 Nov 1996 10:05:13 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002202781000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002202781000002*@MHS> To: Cc: Subject: Updated sections for IPP document Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100002202781" Date: Thu, 21 Nov 1996 10:04:30 -0500 Sender: ipp-owner@pwg.Org Precedence: first-class Status: RO --Boundary=_0.0_=5030100002202781 Classification: Prologue: Epilogue: Scott, here is an update for section 5.1. I took the editorial license of combining section 5.2 with this section. I hope this is all right. It seemd to make sense. In addition, I added an IPP request line and status line, wrote up more detail on Get Jobs, and eliminated the abstract data-types that I thought we had agreed should come out. I think this covers the issues that were discussed in yesterday's call. I am going to take the afternoon off to catch up on some personal things that I've got to get done this week, soiIf you have any questions or want to discuss any of the changes I've made try to call me this morning. I have also written up an appendix with sample flows. This will surely require more work, but I think it reflects the text in section 5.1 pretty accurately. I'll send this by a separate email. --Boundary=_0.0_=5030100002202781 Content-Type: application/octet-stream; name="ipp92-http syntax.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALQAAAAAAAAAA EAAALwAAAAEAAAD+////AAAAAC4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAAAAAAAAAAwAAfCoAALlYAAAAAAAAAAAAAAAAAAAAAAAAACcAAAAA AAB7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAADoHAAAARAAAOgcAADpLAAAAAAAAOksA AAAAAAA6SwAAAAAAADpLAAAAAAAAOksAABQAAAC0SwAAXAUAALRLAAAAAAAAEFEAAAAAAAAQUQAA AAAAABBRAAAQAAAAIFEAAAoAAAAqUQAARgAAALRLAAAAAAAAvFcAAGIAAABwUQAABAAAAHRRAAAW AAAAilEAAAAAAACKUQAAAAAAAIpRAAAAAAAAilEAAGABAADqUgAAzAAAALZTAABoAAAAX1UAAAIA AABhVQAAAAAAAGFVAAAAAAAAYVUAACUAAACGVQAADAEAAJJWAAAMAQAAnlcAAB4AAAAeWAAAWAAA AHZYAABDAAAAvFcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOksAAAAAAAAeVAAAAAAAAAAAFgAXAAEA CwCKUQAAAAAAAIpRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB5UAAAAAAAAHlQAAAAAAAC8VwAAAAAA ABJVAAAAAAAAOksAAAAAAAA6SwAAAAAAAIpRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBRAAAAAAAA ElUAAAAAAAASVQAAAAAAABJVAAAAAAAAHlQAAPQAAAA6SwAAAAAAAIpRAAAAAAAAOksAAAAAAACK UQAAAAAAAF9VAAAAAAAAAAAAAAAAAADAust/rte7AU5LAAAmAAAAdEsAAEAAAAA6SwAAAAAAADpL AAAAAAAAOksAAAAAAAA6SwAAAAAAAB5UAAAAAAAAX1UAAAAAAAASVQAATQAAABJVAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJUFAgT3BlcmF0aW9ucyBVc2luZyBIVFRQDUFsbCBJ UFAgb3BlcmF0aW9ucyBhcmUgZGVmaW5lZCB1c2luZyBIVFRQIGFzIHRoZSB1bmRlcmx5aW5nIGNv bW11bmljYXRpb24gcHJvdG9jb2wuDUhUVFAgT3ZlcnZpZXcNSVBQIGlzIGJhc2VkIG9uIHRoZSBl eGlzdGluZyBIVFRQIHN0YW5kYXJkLiAgSVBQIGlzIGEgbGlnaHR3ZWlnaHQgYXBwbGljYXRpb24t bGV2ZWwgcHJvdG9jb2wgZGVzaWduZWQgd2l0aCB0aGUgSW50ZXJuZXQgaW4gbWluZC4gSXQgaXMg YSBnZW5lcmljLCBzdGF0ZWxlc3MsIG9iamVjdC1vcmllbnRlZCBwcm90b2NvbCB3aGljaCBjYW4g YmUgdXNlZCBmb3IgYW55IHRhc2sgdGhyb3VnaCBleHRlbnNpb24gb2YgaXRzIHJlcXVlc3QgbWV0 aG9kcyAoY29tbWFuZHMpLiAgDUhUVFAgYWxsb3dzIGFuIG9wZW4tZW5kZWQgc2V0IG9mIG1ldGhv ZHMgdG8gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgcHVycG9zZSBvZiBhIHJlcXVlc3QuIEl0IGJ1 aWxkcyBvbiB0aGUgZGlzY2lwbGluZSBvZiByZWZlcmVuY2UgcHJvdmlkZWQgYnkgdGhlIFVuaWZv cm0gUmVzb3VyY2UgTG9jYXRpb24gKFVSTCkgYW5kIG1lc3NhZ2UgZm9ybWF0cyBzaW1pbGFyIHRv IHRob3NlIHVzZWQgYnkgSW50ZXJuZXQgTWFpbCBhbmQgdGhlIE11bHRpcHVycG9zZSBJbnRlcm5l dCBNYWlsIEV4dGVuc2lvbnMgKE1JTUUpLg1IVFRQIGlzIGJhc2VkIG9uIGEgcmVxdWVzdC1yZXNw b25zZSBwYXJhZGlnbS4gQSByZXF1ZXN0aW5nIHByb2dyYW0gKGEgY2xpZW50KSBlc3RhYmxpc2hl cyBhIGNvbm5lY3Rpb24gd2l0aCBhIHJlY2VpdmluZyBwcm9ncmFtIChhIHNlcnZlcikgYW5kIHNl bmRzIGEgcmVxdWVzdCB0byB0aGUgc2VydmVyIGluIHRoZSBmb3JtIG9mIGEgcmVxdWVzdCBtZXRo b2QsIGEgVVJMLCBhbmQgcHJvdG9jb2wgdmVyc2lvbiwgZm9sbG93ZWQgYnkgYSBNSU1FLWxpa2Ug bWVzc2FnZSBjb250YWluaW5nIHJlcXVlc3QgbW9kaWZpZXJzLCBjbGllbnQgaW5mb3JtYXRpb24s IGFuZCBwb3NzaWJseSBwcmludCBkYXRhLiAgVGhlIHNlcnZlciByZXNwb25kcyB3aXRoIGEgc3Rh dHVzIGxpbmUsIGluY2x1ZGluZyBpdHMgcHJvdG9jb2wgdmVyc2lvbiwgYW5kIGEgc3VjY2VzcyBv ciBmYWlsdXJlIGNvZGUsIGZvbGxvd2VkIGJ5IGEgTUlNRS1saWtlIG1lc3NhZ2UgY29udGFpbmlu ZyBzZXJ2ZXIgaW5mb3JtYXRpb24sIGVudGl0eSBtZXRhLWluZm9ybWF0aW9uLCBhbmQgcG9zc2li bHkgc29tZSBjb250ZW50Lg1DdXJyZW50IHByYWN0aWNlIHJlcXVpcmVzIHRoYXQgdGhlIGNvbm5l Y3Rpb24gYmUgZXN0YWJsaXNoZWQgYnkgdGhlIGNsaWVudCBwcmlvciB0byBlYWNoIHJlcXVlc3Qg YW5kIGNsb3NlZCBieSB0aGUgc2VydmVyIGFmdGVyIHNlbmRpbmcgdGhlIHJlc3BvbnNlLiBCb3Ro IGNsaWVudHMgYW5kIHNlcnZlcnMgbXVzdCBiZSBjYXBhYmxlIG9mIGhhbmRsaW5nIGNhc2VzIHdo ZXJlIGVpdGhlciBwYXJ0eSBjbG9zZXMgdGhlIGNvbm5lY3Rpb24gcHJlbWF0dXJlbHksIGR1ZSB0 byB1c2VyIGFjdGlvbiwgYXV0b21hdGVkIHRpbWUgb3V0LCBvciBwcm9ncmFtIGZhaWx1cmUuDUlQ UCBPcGVyYXRpb24gRW5jb2RpbmcNSVBQIG1lc3NhZ2VzIGNvbnNpc3Qgb2YgcmVxdWVzdHMgZnJv bSBjbGllbnQgdG8gc2VydmVyIGFuZCByZXNwb25zZXMgZnJvbSBzZXJ2ZXIgdG8gY2xpZW50Lg0J CUhUVFAgTUVTU0FHRSA9IFJlcXVlc3QgfCBSZXNwb25zZQ0NUmVxdWVzdHMgYW5kIHJlc3BvbnNl cyB1c2UgdGhlIGdlbmVyaWMgbWVzc2FnZSBmb3JtYXQgb2YgUkZDIDgyMiBmb3IgdHJhbnNmZXJy aW5nIGVudGl0aWVzLiBCb3RoIG1lc3NhZ2VzIG1heSBpbmNsdWRlIG9wdGlvbmFsIGhlYWRlciBm aWVsZHMgYW5kIGFuIGVudGl0eSBib2R5LiBUaGUgZW50aXR5IGJvZHkgaXMgc2VwYXJhdGVkIGZy b20gdGhlIGhlYWRlcnMgYnkgYSBudWxsIGxpbmUgKGEgbGluZSB3aXRoIG5vdGhpbmcgcHJlY2Vk aW5nIHRoZSBDUkxGKS4gDQ0JCVJlcXVlc3QgPSBSZXF1ZXN0LWxpbmUNCQkJICAgICogKEdlbmVy YWwtSGVhZGVyDQkJCSAgICB8ICBSZXF1ZXN0LUhlYWRlciAgDQkgICAgICAgICAgICAgICAgfCAg RW50aXR5LUhlYWRlcikNCQkJICAgIENSTEYNCQkJICAgIFsgRW50aXR5LUJvZHkgXQ0NCQlSZXNw b25zZSA9IFN0YXR1cy1saW5lDQkJCSAgICAqIChHZW5lcmFsLUhlYWRlcg0JCQkgICAgfCAgUmVx dWVzdC1IZWFkZXIgIA0JICAgICAgICAgICAgICAgIHwgIEVudGl0eS1IZWFkZXIpDQkJCSAgICBD UkxGDQkJCSAgICBbIEVudGl0eS1Cb2R5IF0NIA0NQWxsIElQUCBoZWFkZXJzIGNvbmZvcm0gdG8g dGhlIHN5bnRheA0JCUlQUCBIZWFkZXIgPSBmaWVsZCBuYW1lIJM6lCBbZmllbGQtdmFsdWVdIENS TEYuDQ1JUFAvMS4wIGRlZmluZXMgdGhlIG9jdGV0IHNlcXVlbmNlIENSIExGIGFzIHRoZSBlbmQt b2YtbGluZSBtYXJrZXIgZm9yIGFsbCBwcm90b2NvbCBlbGVtZW50cyBleGNlcHQgdGhlIGVudGl0 eS1ib2R5LiBJbiB0aGlzIGRvY3VtZW50LCB0aGUgc2VxdWVuY2UgQ1IgTEYgaXMgc2hvd24gYXMg Q1JMRi4NTm90ZSB0aGF0IEhUVFAgMS4xIGRlZmluZXMgYSBzbGlnaHRseSBkaWZmZXJlbnQgc3lu dGF4LCBhbGxvd2luZyBmb3IgZHluYW1pY2FsbHkgZ2VuZXJhdGVkIG1lc3NhZ2VzIHRvIGJlIHRy YW5zbWl0dGVkLiBUaGlzIHdvdWxkIGJlIHJlcXVpcmVkIGZvciBjYXNlcyBzdWNoIGFzIFBDIGRy aXZlciBnZW5lcmF0ZWQgUHJpbnQgT3BlcmF0aW9ucy4gIEhUVFAgMS4xIGRlZmluZXMgYSBtZXNz YWdlIGhlYWRlciB3aGljaCBzcGVjaWZpZXMgYSB0cmFuc2ZlciBlbmNvZGluZyBjYWxsZWQgk2No dW5rc5QuIA1IVFRQIFJlcXVlc3QtSGVhZGVyIEZpZWxkcw1IVFRQIHJlcXVlc3QgaGVhZGVyIGZp ZWxkcyBhbGxvdyB0aGUgY2xpZW50IHRvIHBhc3MgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgcmVxdWVzdCwgYW5kIGFib3V0IHRoZSBjbGllbnQgaXRzZWxmLCB0byB0aGUgc2VydmVy LiAgQWxsIGhlYWRlciBmaWVsZHMgYXJlIG9wdGlvbmFsIGFuZCB3aGVuIHVzZWQgaXQgaXMgYXNz dW1lZCB0aGF0IElQUCB3b3VsZCB1c2UgdGhlc2UgaGVhZGVycyBpbiBhIHN0YW5kYXJkIHdheS4g IElQUCByZXF1ZXN0cyB3aWxsIGJlIGNvbXBsZXRlbHkgZW5jYXBzdWxhdGVkIHdpdGhpbiB0aGUg ZW50aXR5IGJvZHkgb2YgYW4gSFRUUCByZXF1ZXN0LiBUaGUgSFRUUCBFbnRpdHktSGVhZGVyIGhh cyB0aGUgZm9ybSANDUhUVFAgRW50aXR5LUhlYWRlciA9CSBDb250ZW50LUVuY29kaW5nDQkJCQkJ CQkJIHwgQ29udGVudC1MZW5ndGgNCQkJCQkJCQkgfCBDb250ZW50LVR5cGUNCQkJCQkJCQkgfCBl eHRlbnNpb24taGVhZGVyDQ1UaGUgQ29udGVudC1MZW5ndGggZmllbGQgbXVzdCBhbHdheXMgYmUg YSB2YWxpZCBsZW5ndGgsIFRoaXMgbWVhbnMgdGhhdCBmb3IgYW55IFByaW50IE9wZXJhdGlvbnMg YmFzZWQgb24gSFRUUCAxLjAsIHRoZSBlbnRpcmUgY29udGVudCBtdXN0IGJlIGdlbmVyYXRlZCBi ZWZvcmUgdGhpcyBoZWFkZXIgY2FuIGJlIGJ1aWx0LiAgSFRUUCAxLjEgcHJvdmlkZXMgdGhlIG5v dGlvbiBvZiCTY2h1bmtzlCB3aGljaCB3aWxsIGFsbG93IHRoZSBjb250ZW50IHRvIGJlIGdlbmVy YXRlZCBkeW5hbWljYWxseSBhcyB0aGUgZGF0YSBpcyBzZW50Lg0NQ29udGVudC1UeXBlIHdpbGwg YWx3YXlzIGJlIJNBcHBsaWNhdGlvbi9JUFCULg1JUFAgUmVxdWVzdC1MaW5lDVRoZSBmaXJzdCBs aW5lIG9mIHRoZSBlbnRpdHkgYm9keSBpbiBhbiBJUFAgb3BlcmF0aW9uIGlzIHRoZSBJUFAgUmVx dWVzdC1MaW5lLiBUaGUgUmVxdWVzdC1MaW5lIGRlZmluZXMgdGhlIE9wZXJhdGlvbiBhbmQgdGhl IElQUCBWZXJzaW9uLg0NCUlQUCBSZXF1ZXN0LUxpbmUgPQlPcGVyYXRpb24gdG9rZW4gIElQUC8x LjANDQlPcGVyYXRpb24gdG9rZW4JPSAJUHJpbnQgfCBDYW5jZWxKb2IgfCBHZXRBdHRyaWJ1dGVz IHwgDQkJCQkJCQlHZXRKb2JzDQ1QcmludA1XaGVuIGFuIGVuZCB1c2VyIHN1Ym1pdHMgYSBqb2Is IHRoZSAgY2xpZW50IHN1Ym1pdHMgYSBQcmludCBSZXF1ZXN0IGFjY29yZGluZyB0byB0aGUgc3lu dGF4IGFuZCBzZW1hbnRpY3Mgb2YgdGhpcyBzdGFuZGFyZCBhbmQgcmVjZWl2ZXMgYSBQcmludCBS ZXNwb25zZSBhY2NvcmRpbmcgdG8gdGhpcyBzdGFuZGFyZC4gIFRoZSBlbmQtdXNlciBvciBzdWJt aXR0aW5nIGFwcGxpY2F0aW9uIHNlbGVjdHMgYSBQcmludGVyIHdoaWNoIG1heSBpbXBseSBhIEpv YiBUZW1wbGF0ZS4gDVtGdXJ0aGVyIHdvcmsgbmVlZHMgdG8gZG9uZSB0byBkZWZpbmUgdGhlIGFi b3ZlIGNvbmNlcHQuXQ1UaGUgZm9sbG93aW5nIGFic3RyYWN0IGRhdGEgdHlwZXMgYXJlIHBhcnQg b2YgdGhlIFByaW50IFJlcXVlc3QuICBOb3RlOiBUaGUgUHJpbnRlciBuYW1lIGlzIG5vdCBuZWVk ZWQgc2luY2UgaXQgaXMgdGhlIHRhcmdldCBvZiB0aGUgZW50aXJlIG9wZXJhdGlvbi4gQSBQcmlu dCBKb2IgY29udGFpbnMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCBieSB0aGUgUHJpbnQgb2JqZWN0 IHRvIHByaW50IGEgZG9jdW1lbnQgb3Igc2V0IG9mIGRvY3VtZW50cy4gIFdoZW4gdGhlIHByaW50 IG9wZXJhdGlvbiBpcyBpbnZva2VkLCB0aGUgRW50aXR5LUJvZHkgaW4gdGhlIEhUVFAgcmVxdWVz dCBpbmNsdWRlcyBhbiBJUFAgUHJpbnQgSm9iLiBUaGUgY29uY3JldGUgc3ludGF4IG9mIHRoZSBQ cmludCBKb2IgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIHh4eC4gDUpvYiBhbmQgRG9jdW1lbnQgQXR0 cmlidXRlcwdBIHNldCBvZiBKb2Igb2JqZWN0IGFuZCBEb2N1bWVudCBhdHRyaWJ1dGVzIGFzIGRl ZmluZWQgaW4gc2VjdGlvbiB4eHgHB0RvY3VtZW50IENvbnRlbnRzB0RvY3VtZW50IGNvbnRlbnQg aXMgb3B0aW9uYWwgYW5kIG5vdCBpbmNsdWRlZCB3aGVuIGEgVVJMIGlzIHByb3ZpZGVkIHRvIHBv aW50IHRvIHRoZSBjb250ZW50LgcHDQ1QcmludCBSZXNwb25zZQ1UaGUgZm9sbG93aW5nIGFic3Ry YWN0IGRhdGEgdHlwZXMgYXJlIHBhcnQgb2YgdGhlIFByaW50IFJlc3BvbnNlOg0NSm9iLUlkZW50 aWZpZXIHQSBVUkwgVXNlZCBmb3IgYWxsIG90aGVyIG9wZXJhdGlvbnMgb24gdGhpcyBKb2IuBwdK b2IgU3RhdHVzB0N1cnJlbnQtam9iLXN0YXRlBwdQcmludGVyIFN0YXRlB1ByaW50ZXItc3RhdGUH B01lc3NhZ2UHT3B0aW9uYWwgbWVzc2FnZSBOb3RlOiBJcyB0aGlzIG5lZWRlZD8HB0Vycm9ycwdP cHRpb25hbCBFcnJvciBJbmZvcm1hdGlvbgcHDQ1DYW5jZWxKb2INVGhlIGZvbGxvd2luZyBhYnN0 cmFjdCBkYXRhIHR5cGVzIGFyZSBwYXJ0IG9mIHRoZSBDYW5jZWwgSm9iIFJlcXVlc3QuIFRoaXMg b3BlcmF0aW9uIGFsbG93cyBhIHVzZXIgdG8gY2FuY2VsIG9uZSBzcGVjaWZpYyBQcmludCBKb2Ig YW55IHRpbWUgYWZ0ZXIgdGhlIHByaW50IGpvYiBoYXMgYmVlbiBlc3RhYmxpc2hlZCBvbiB0aGUg UHJpbnRlciBPYmplY3QuIFNvbWUgcGFnZXMgbWF5IGJlIHByaW50ZWQgYmVmb3JlIGEgam9iIGlz IHRlcm1pbmF0ZWQgaWYgcHJpbnRpbmcgaGFzIGFscmVhZHkgc3RhcnRlZCB3aGVuIHRoZSBDYW5j ZWwgSm9iIG9wZXJhdGlvbiBpcyByZWNlaXZlZC4NVGhlIENhbmNlbCBIVFRQIHJlcXVlc3Qgd2ls bCBiZSBzZW50IHRvIHRoZSBVUkwgaWRlbnRpZnlpbmcgdGhlIGpvYiB0byBiZSBjYW5jZWxlZC4g DQ0NTWVzc2FnZQdPcHRpb25hbCBtZXNzYWdlIHRvIHRoZSBvcGVyYXRvci4HBw1DYW5jZWxKb2Ig UmVzcG9uc2UNVGhlIGZvbGxvd2luZyBhYnN0cmFjdCBkYXRhIHR5cGVzIGFyZSBwYXJ0IG9mIHRo ZSBDYW5jZWwgSm9iIFJlc3BvbnNlOg0NSm9iIFN0YXR1cwdPcHRpb25hbCBKb2Igc3RhdHVzIGlu Zm9ybWF0aW9uBwdFcnJvcnMHT3B0aW9uYWwgRXJyb3IgSW5mb3JtYXRpb24HBw1HZXRBdHRyaWJ1 dGVzDVRoaXMgb3BlcmF0aW9uIGFsbG93cyBhIHVzZXIgdG8gb2J0YWluIGluZm9ybWF0aW9uIGZy b20gdGhlIFByaW50IG9iamVjdCBjb25jZXJuaW5nIGpvYnMsIHByaW50ZXJzLCBhbmQgcHJpbnQg cXVldWVzLCBiYXNlZCBvbiBJU08gMTAxNzUuIFRoZSBlbnRpdHktYm9keSBvZiB0aGUgR2V0IEF0 dHJpYnV0ZXMgb3BlcmF0aW9uIGNvbnRhaW5zIHRoZSBzZXQgb2YgYXR0cmlidXRlcyB0aGF0IHRo ZSByZXF1ZXN0ZXIgaXMgaW50ZXJlc3RlZCBpbi4gIEhvd2V2ZXIsIHRoZSBhdHRyaWJ1dGUgdmFs dWVzIG1heSBiZSBudWxsIGFuZCBhcmUgaWdub3JlZCBieSB0aGUgc2VydmVyLiBUaGUgYXR0cmli dXRlIGxpc3QgIGlzIHJldHVybmVkIGluIHRoZSByZXNwb25zZSB3aXRoIHRoZSBhcHByb3ByaWF0 ZSBhdHRyaWJ1dGUgdmFsdWVzIGZpbGxlZCBpbi4gSWYgbm8gYXR0cmlidXRlIGxpc3QgaXMgc3Vw cGxpZWQsIHRoZW4gYWxsIGF0dHJpYnV0ZXMgZGVmaW5lZCBmb3IgdGhhdCBvYmplY3QgYXJlIHJl dHVybmVkLiBUaGUgZm9sbG93aW5nIGFic3RyYWN0IGRhdGEgdHlwZXMgYXJlIHBhcnQgb2YgdGhl IEdldCBBdHRyaWJ1dGVzICBSZXF1ZXN0Og1TZWxlY3RvcgdKb2ItSWRlbnRpZmllciAoVVJMKSBv cg1QcmludGVyIFVSTAcHUmVxdWVzdGVkIEF0dHJpYnV0ZXMHQSBzZXQgb2YgYXR0cmlidXRlcyBp biB3aGljaCB0aGUgcmVxdWVzdG9yIGlzIGludGVyZXN0ZWQHBw1HZXRBdHRyaWJ1dGVzIFJlc3Bv bnNlDVRoZSBmb2xsb3dpbmcgYWJzdHJhY3QgZGF0YSB0eXBlcyBhcmUgcGFydCBvZiB0aGUgR2V0 IEF0dHJpYnV0ZXMgIFJlc3BvbnNlOg1SZXN1bHQgQXR0cmlidXRlcwdUaGUgcmVxdWVzdGVkIGF0 dHJpYnV0ZXMgb2YgdGhlIG9iamVjdCAHB0Vycm9ycwdPcHRpb25hbCBlcnJvciBpbmZvcm1hdGlv bgcHDUdldEpvYnMNVGhlIEdldCBKb2JzIG9wZXJhdGlvbiBhbGxvd3MgYSBjbGllbnQgdG8gcmV0 cmlldmUgYSBsaXN0IG9mIHByaW50IGpvYnMgYmVsb25naW5nIHRvIHRoZSB0YXJnZXQgUHJpbnRl ciBvYmplY3QuIEEgbGlzdCBvZiBhdHRyaWJ1dGVzIHRoZSBjbGllbnQgaXMgaW50ZXJlc3RlZCBp biBzZWVpbmcgbWF5IGJlIGFwcGVuZGVkIHRvIHRoZSByZXF1ZXN0LiBJZiBubyBhdHRyaWJ1dGVz IGFyZSBhc2tlZCBmb3IgdGhlIGRlZmF1bHQgc2V0IG9mIGpvYi1uYW1lIGFuZCB0b3RhbC1qb2It b2N0ZXRzIGlzIHJldHVybmVkIGZvciBlYWNoIGpvYi4gSm9icyB3aWxsIGJlIHJldHVybmVkIGlu IHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IGFyZSBzY2hlZHVsZWQgdG8gcHJpbnQuDVRoZSBmb2xs b3dpbmcgYWJzdHJhY3QgZGF0YSB0eXBlcyBhcmUgcGFydCBvZiB0aGUgR2V0IEpvYnMgUmVxdWVz dDoNDVJlcXVlc3RlZCBBdHRyaWJ1dGVzB0FuIG9wdGlvbmFsIHNldCBvZiBqb2IgYXR0cmlidXRl cyBpbiB3aGljaCB0aGUgcmVxdWVzdG9yIGlzIGludGVyZXN0ZWQHBw0NR2V0IEpvYnMgUmVzcG9u c2UNVGhlIGZvbGxvd2luZyBhYnN0cmFjdCBkYXRhIHR5cGVzIGFyZSBwYXJ0IG9mIHRoZSBHZXQg Sm9icyBSZXNwb25zZToNDVJlc3VsdCBBdHRyaWJ1dGVzB0F0dHJpYnV0ZSBzZXQgY29udGFpbmlu ZyB0aGUgcmV0dXJuZWQgcmVzdWx0cy4HB0Vycm9ycwdPcHRpb25hbCBFcnJvciBJbmZvcm1hdGlv bgcHDVRoZSBQcmludCBKb2INVGhlIGVudGl0eSBib2R5IG9mIGEgcHJpbnQgcmVxdWVzdCB3aWxs IGNvbnRhaW4gYSBQcmludCBKb2IsIGFzIGRlZmluZWQgYmVsb3cuIFRoZSBoZWFkZXJzIGRlZmlu ZWQgaGVyZSBhcmUgSVBQIGhlYWRlcnMsIGJ1dCBmb2xsb3cgdGhlIHNhbWUgc3ludGF4IGFzIHRo ZSBiYXNpYyBIVFRQIGhlYWRlcnMuIA0NCQlQcmludCBKb2IgPSBQcmludC1Kb2ItT2JqZWN0LUhl YWRlcgkJCXNlY3Rpb24gKDEuMi4xKQ0JCQkJCQlbSm9iIEF0dHJpYnV0ZXNdCQkJCXNlY3Rpb24g KDEuMi40KQ0JCQkJCQkqKERvY3VtZW50cykNCQkNCUpvYiBBdHRyaWJ1dGUgPSBBdHRyaWJ1dGUg bmFtZSA6IEF0dHJpYnV0ZSB2YWx1ZSBDUkxGDQkJCQ0JRG9jdW1lbnQgPQlEb2N1bWVudC1IZWFk ZXIJCQlzZWN0aW9uICgxLjIuMikNCVtEb2N1bWVudCBhdHRyaWJ1dGVzXQkJc2VjdGlvbiAoMS4y LjUpDQlbQ29udGVudC1IZWFkZXIJCQlzZWN0aW9uICgxLjIuMykNCQkgICAgIAkJIGNvbnRlbnRd CQkJCQ0NUHJpbnQgSm9iIE9iamVjdCBIZWFkZXINCQlQcmludC1Kb2ItT2JqZWN0IEhlYWRlciA9 IENvbnRlbnQtRW5jb2RpbmcNCQkJCQkJIHwgQ29udGVudC1MZW5ndGgNCQkJCQkJIHwgQ29udGVu dC1UeXBlDQkJCQkJCSB8IGV4dGVuc2lvbi1oZWFkZXINDSBDb250ZW50LVR5cGUgaXMgYWx3YXlz IJNJUFAgUHJpbnQgT2JqZWN0lC4gT3RoZXIgaGVhZGVyIGZpZWxkcyBhcmUgYXMgZGVmaW5lZCBm b3IgSFRUUCAxLjAuDURvY3VtZW50IEhlYWRlcg1UaGUgZG9jdW1lbnQgaGVhZGVyIGFsbG93cyB0 aGUgaW5zZXJ0aW9uIG9mIG11bHRpcGxlIGRvY3VtZW50cyB3aXRoaW4gYSBqb2IuIEF0IHRoaXMg cG9pbnQgb25seSBhIGxpbWl0ZWQgbnVtYmVyIG9mIGRvY3VtZW50IGF0dHJpYnV0ZXMgYXJlIGRl ZmluZWQuIEhvd2V2ZXIsIHRoaXMgc3RydWN0dXJlIGFsbG93cyB0aGUgYWRkaXRpb24gb2Ygb3Ro ZXIgYXR0cmlidXRlcyB3aGljaCBjYW4gYmUgc3BlY2lmaWVkIG9uIGEgZG9jdW1lbnQgYm91bmRh cnkuDURvY3VtZW50IEhlYWRlciA9CUNvbnRlbnQtRW5jb2RpbmcNCQkJCXwgQ29udGVudC1MZW5n dGgNCQkJCXwgQ29udGVudC1UeXBlDQkJCQl8IGV4dGVuc2lvbi1oZWFkZXINDUNvbnRlbnQgdHlw ZSBpcyBhbHdheXMgk0lQUCBEb2N1bWVudJQuIE90aGVyIGhlYWRlciBmaWVsZHMgYXJlYSBhcyBk ZWZpbmVkIGluIEhUVFAgMS4wLg1Eb2N1bWVudC1Db250ZW50IEhlYWRlcg1UaGUgZG9jdW1lbnQt Y29udGVudC1oZWFkZXIgcHJvdmlkZXMgYWRkaXRpb25hbCBtZXRhLWluZm9ybWF0aW9uIGFib3V0 IHRoZSBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGNvbnRlbnQgaGVhZGVyIGlzIGFuIG9wdGlvbmFs IGZpZWxkIGFuZCB3b3VsZCBub3QgYmUgcHJlc2VudCBpZiB0aGUgZG9jdW1lbnQgd2FzIHBvaW50 ZWQgdG8gYnkgYSBkb2N1bWVudCBVUkwgYXR0cmlidXRlLiBJdCBpcyBjb21wb3NlZCBvZiBhIG51 bWJlciBvZiBkb2N1bWVudCBoZWFkZXIgZmllbGRzIGFzIGZvbGxvd3M6DQ1Eb2N1bWVudC1Db250 ZW50LUhlYWRlciA9CSBDb250ZW50LUVuY29kaW5nDQkJCQkJCSB8IENvbnRlbnQtTGVuZ3RoDQkJ CQkJCSB8IENvbnRlbnQtVHlwZQ0JCQkJCQkgfCBleHRlbnNpb24taGVhZGVyDQ1Db250ZW50LVR5 cGUgaXMgZGVmaW5lZCBhcyA6DQkJQ29udGVudC1UeXBlID0gRGF0YSBTdHJlYW0gRm9ybWF0IJMv lCBWZXJzaW9uDQ1UaHVzLCBmb3IgZXhhbXBsZSwgaWYgdGhlIGRvY3VtZW50IHRvIGJlIHByaW50 ZWQgd2FzIGEgUG9zdHNjcmlwdCBMZXZlbCAyIGRvY3VtZW50LCB0aGUgQ29udGVudC1UeXBlIHdv dWxkIGJlIHNwZWNpZmllZCBhczoNDQkJCUNvbnRlbnQtVHlwZTogUG9zdHNjcmlwdC8yLjANDU90 aGVyIGhlYWRlciBmaWVsZHMgYXJlIGFzIGRlZmluZWQgYnkgSFRUUCAxLjAuDUpvYiBBdHRyaWJ1 dGVzDUpvYiBhdHRyaWJ1dGVzIGFyZSBkZWZpbmVkIGluIHNlY3Rpb24geHh4LiAgQXR0cmlidXRl cyB3aWxsIGFsd2F5cyBiZSBzZW50IGFzDQ1Kb2ItQXR0cmlidXRlID0gYXR0cmlidXRlIG5hbWUg kzqUIEF0dHJpYnV0ZSB2YWx1ZSAgQ1JMRg0NQXR0cmlidXRlIHZhbHVlID0gVmFsdWUgfCAqKFZh bHVlIJMslCBWYWx1ZSkNDQ1Eb2N1bWVudCBBdHRyaWJ1dGVzDURvY3VtZW50IGF0dHJpYnV0ZXMg YXJlIGRlZmluZWQgaW4gc2VjdGlvbiB5eXkuICBBdCB0aGlzIHBvaW50IGEgbGltaXRlZCBudW1i ZXIgb2YgYXR0cmlidXRlIG1heSBiZSBzcGVjaWZpZWQgb24gYSBkb2N1bWVudCBiYXNpcy4gVGhl IHN5bnRheCBmb3IgYSBkb2N1bWVudCBhdHRyaWJ1dGUgaXMNDURvY3VtZW50LUF0dHJpYnV0ZSA9 IGF0dHJpYnV0ZSBuYW1lIJM6lCBBdHRyaWJ1dGUgdmFsdWUgIENSTEYNDUF0dHJpYnV0ZSB2YWx1 ZSA9IFZhbHVlIHwgKihWYWx1ZSCTLJQgVmFsdWUpDQ0NDQ1JbnRlcm5ldC1EcmFmdAlJUFAgKFZl ci4gMC45MiBOb3ZlbWJlciAxOCwgMTk5NikJTm92ZW1iZXIgMTk5Ng0NZGVCcnksIEhhc3Rpbmdz LCBIZXJyaW90LElzYWFjc29uCQkJCQkJCQlbUGFnZSATUEFHRRQ1FV0NDQ0NIQCOAJgBmQqaAQCb sAGk0C+l4D2mCAencAiooAWpoAWqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAC5CgAAvQoAADkLAAA+CwAARQsA AM0LAADSCwAA2QsAAOkLAADsCwAAPgwAAEUMAADrDAAA7wwAAB4QAAAsEAAATREAAFkRAACPEgAA kBIAAPAhAAD0IQAAGSMAACYjAACcKAAAoCgAAMkpAADNKQAAACoAAG8qAABwKgAAdCoAAHUqAAB2 KgAAdyoAAHsqAAB8KgAAnyoAAAD7APj2APj2APYA+AD4APYA9gD0APgA9gD4APgAAO8A7+3vAADr AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnUBAANhAAQI dQFEBAAAAAAAA10AAAJVgQAFVYFjEAAHVYFagWMQAAAmAAMAABoDAABuAwAAfAMAAIgEAACsBQAA 3QcAACAJAAA3CQAAkwkAALcJAAC4CQAAwQoAAMIKAADbCgAA9AoAAA8LAAAyCwAAPgsAAFULAABW CwAAbwsAAIgLAACjCwAAxgsAANILAADpCwAA6wsAAOwLAAASDAAARAwAAEUMAADxDAAAEA4AACsO AACjDwAApA8AAP4AAVgg2AD8AAJYINgA+gABWCDYAPwABVgg2AD8AAVYINgA/AAJWCDYAPwABlgg 2AD6AAFYINgA/AACWCDYAN0AAVgg2ADdAAFYINgA/AAFWCDYAN0AAVgg2ADdAAFYINgA3QABWCDY AN0AAVgg2ADdAAFYINgA3QABWCCyAN0AAVgg2ADdAAFYINgA3QABWCDYAN0AAVgg2ADdAAFYINgA 3QABWCDYAN0AAVggsgDdAAFYINgA3QABWCDrAN0AAVgg6wD8AAFYINgA3QABWCDYAN0AAVggsgD8 AANYINgA/AAFWCDYANsAAVgg2AD8AAZYINgA3QABWCDYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQQAABwAAAw0/wEAOAIAAQAUAAEAaAEAAAAAAAC3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAwAAAQ8AAAECACSkDwAAyw8AAOUPAAD9DwAAGRAAABoQAABM EQAATREAAHwRAACNEQAAGBIAABkSAABGEgAARxIAAIASAACPEgAAkBIAAJYSAACmEwAA4BMAAIYV AACiFQAA6BUAAOkVAAD7FQAAWRYAAFoWAADhAAFYINgAxAABWCDYAMQAAVgg2ADEAAFYINgAxAAB WCDYAMIE/1ggOwXEAAFYINgAwgABWCDrAMAAAVgg2AC8AANYINgAvAABWCDYALwAAVgg2AC8AAFY INgAvAABWCDYALwAAVgg2ADCAAFYIPAAwAABWCDYAMIABVgg2ADCAAFYINgAwgAHWCDYALkAA3YH 2AC5AAKEFtgAqwAChBbYALkAAnYH2AC5AAKEFtgAqwAChBbYAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAYARkBtgEAuGAAvZIBvggAAkYCfArA IQAAAgAAGAEAAwAAEWgBAAABBAAAAQ8AABwAAAw0/wEAOAIAAQAUAAEAaAEAAAAAAAC3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAT0AIMNP8BADgCAAEAFAABAGgBAAAAAAAAtwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGloWAABbFgAAXBYAAGsWAACtFgAArhYAAL0W AADuFgAAvQABWCDYAHsAAVgg2AB5AAFYINgAdwABWCDYADQAAVgg2AAxAAF2B9gAMQABhBbYAAAA AAAAAAAAAAAAAAAAAAAAAgAAGAEAQgAAEWgBMfAAMPAAD3cAJ8j7MP1oAdACOASgBQgHcAjYCUAL qAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAqAC3QL6AycDVAOBA74D2wQIBDUEYg SQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAAQQAAEEAADHwADDw AA93ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAk YCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEIAABFIAzHwADDwAA93ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKw ExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH7hYAAO8WAAD6FgAADBcAAA0XAAAbFwAAKRcA ACoXAAAyFwAAWRcAAFoXAABhFwAAfBcAAH0XAAB+FwAAfxcAAIkXAADWGAAAKxkAACwZAAAtGQAA NRkAAFcZAABYGQAA8gABhBbYAO8AAXYH2ADvAAGEFtgA8gABhBbYAO8AAXYH2ADvAAGEFtgA8gAB hBbYAO8AAXYH2ADvAAGEFtgA8gABhBbYAO8AAXYH2ADvAAGEFtgA8gABhBbYAO0AAVgg2ADtAAFY INgA6wABWCDYAOkABlgg2ADpAAJYINgA6QABWCDYAKYAAVgg2ADvAAF2B9gA7wABhBbYAPIAAYQW 2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABCAAARaAEx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuo DBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAABBAAAAQAAAAIAABgB AA0AABgBGQG2AQC4YAC9kgG+CAACRgJ8CsAhABdYGQAAWRkAAGwZAACzGQAAtBkAAL8ZAADfGQAA 4BkAAOcZAAACGgAAAxoAAAQaAAASGgAAYhwAAGscAACDHAAAjxwAAL4AAVgg2AC8AAFYINgAeQAC WCDYAHkAAVgg2AB2AAF2B9gAdgABhBbYAGgAAYQW2AB2AAF2B9gAdgABhBbYAGgAAYQW2ABmAAFY INgAvAABWCDYAGYAClgg2AB2AAFfB9gAdgABQRbYAHYAAUEW2AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABDwAADQAAGAEZAbYBALhgAL2SAb4IAAJGAnwKwCEAAAIAABgBAEIAABFoATHwADDwAA93 ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcw KgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQQAAEEAADHwADDwAA93ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgV gBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEI8cAACQHAAApRwAAN4cAADfHAAA4BwAAPccAABD HQAAVR0AAH0dAAB+HQAAhR0AAKAdAAChHQAAoh0AAKodAAAlHwAAaR8AAGofAADyAAFBFtgA7wAC XwfYAO8AAkEW2ADyAAJBFtgArAABWCDYAKoAAVgg2ACoAAJYINgA7wACXwfYAO8AAUEW2ADyAAFB FtgA7wABXwfYAO8AAUEW2ADyAAFBFtgAqAABWCDYAKoAAVgg2ACoAAZYINgAZQACWCDYAGUAAVgg 2ABCAAARaAEx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQ GbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAABBAAAQgAAEUgDMfAAMPAAD3cAJ8j7MP1oAdACOASg BQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAqAC3QL6AycDVAOBA7 4D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAYAQAN AAAYARkBtgEAuGAAvZIBvggAAqACvwrAIQASah8AAH8fAADGHwAAxx8AAMgfAADJHwAA2x8AACAg AAAhIAAAMyAAAGIgAABjIAAAaiAAAIUgAACGIAAAhyAAAJUgAABFIQAA/QACdgfYAP0AAoQW2ADv AAKEFtgArQABWCDYAGoAAVgg2ABoAAFYINgAagACWCDYAGoAAVgg2AD9AAJ2B9gA/QABhBbYAO8A AYQW2AD9AAF2B9gA/QABhBbYAO8AAYQW2ACtAAFYINgAZgABWCDYAGQAA1gg2AAAAAAAAAAAAAAB DwAAAQMAAAEEAABCAAARaAEx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgS sBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAADHwADDwAA93ACfI+zD9aAHQAjgEoAUI B3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9 sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AABgBGQG2 AQC4YAC9kgG+CAACRgJ8CsAhAAACAAAYARFFIQAARiEAAH4hAACoIQAAuyEAAL4hAAD1IQAA+SEA ACciAABPIgAAciIAAIkiAACKIgAAoiIAAM8iAADnIgAA/SIAABcjAAAYIwAAdSMAAIUjAACJJAAA rCQAAMEkAADUJAAA6yQAAOwkAABEJQAAXCUAAOMAAVgg2ADjAAFYINgA4wABWCDYAOMAAVgg2ADj AAFYINgAxAABWCDYAMQAAVgg2ADEAAFYINgApAABWCDYAKQAAVgg2ADEAAFYINgAxAABWCDYAKIA AVgg2ADjAAFYINgA4wABWCDYAOMAAVgg2ADjAAFYINgA4wABWCDYAKAE/1ggswKiAAFYINgAoAAF WCDYAMQAAVgg2ADjAAFYINgA4wABWCDYAOMAAVgg2ADjAAFYINgAoAACWCDYAKIAAVgg2AAAAAAA AAAAAAEPAAABBAAAHwAAEaAFE9ACDDT/AQA4AgABABQAAQBoAQAAAAAAALcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB4AABPQAgw0/wEAOAIAAQAUAAEAaAEAAAAAAAC3AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAADDT/AQA4AgABABQAAQBoAQAAAAAAALcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHFwlAAB4JgAAeSYAAKUmAAC9JgAA0yYAAO0mAADuJgAA CycAADsnAAA8JwAAuCcAALknAADZJwAA2icAAAooAAAZKAAAZygAAGgoAAChKAAAoigAAM8oAADQ KAAA0SgAAOUoAACPKQAAkCkAAM4pAADPKQAA/CkAAP4ABVgg2AD8AAFYINgA3QABWCDYAMAAAVgg 2ADAAAFYINgAwAABWCDYAMAAAVgg2AD+AAFYINgA/AABWCDYAPwAAVgg2AD+AAJYINgA/AABWCDY APwAAVgg2AD8AAFYINgA/gABWCDYAL4AAVgg2AD+AAJYINgAwAABWCDYAN0AAVgg2ADAAAFYINgA 3QABWCDYAN0AAVgg2ADdAAFYINgAvgABWCDYAP4AA1gg2AD8AAFYINgA3QABWCDYAMAAAVgg2ADd AAFYINgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQQAABwAAAw0/wEAOAIAAQAUAAEAaAEAAAAAAAC3AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAeAAAT0AIMNP8BADgCAAEAFAABAGgBAAAAAAAAtwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAABDwAd/CkAAP0pAAD+KQAA/ykAAAAqAAA/KgAAQCoAAHkqAAB6 KgAAeyoAAL4AAVgg2AB7AAFYINgAvgABWCDYADgAAVgg2AA2AAFYINgANgAAAAAAADYAAlgg2AA2 AAAAAAAANgAAAAAAAAAAAAAAAQAAAEIAABFIAzHwADDwAA93ACfI+zD9aAHQAjgEoAUIB3AI2AlA C6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BG IEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQgAAEWgBMfAAMPAAD3cA J8j7MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAq AC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABBAAAx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQ GbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAl7KgAAfCoAAL0AAVgg2AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABCAAARSAMx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQ GbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4AIwAIAAEASwAPAAAAAAAyAABA8f8CADIABk5vcm1hbAAY AAAADxQABmgB0AI4BKAFCAdwCEBAQEBAQAYAXQMAYQkEXgABQAEA8gBeAAlIZWFkaW5nIDEAAD8A AQAIAQ0BFvAADDQAAAEEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAYAXQMAaxwAXAACQAEAAgBcAAlIZWFkaW5nIDIAAD8AAgAIAQ0CFvAADDQAAAAEAAAB gAAAAQAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAXQMAAFgAA0AB APIAWAAJSGVhZGluZyAzAAA/AAMACAENAxbwAAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABEABAAIAWAAJSGVhZGluZyA0AAA/AAQACAEN BBbwAAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAF4ABUABAAIAXgAJSGVhZGluZyA1AABAAAUADQUV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAA AAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAF0CAGMWAF4ABkABAAIAXgAJSGVh ZGluZyA2AABAAAYADQYV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAFAFaBYxYAAFwAB0ABAAIAXAAJSGVhZGluZyA3AABAAAcADQcV8AAW PAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD AF0CAABeAAhAAQACAF4ACUhlYWRpbmcgOAAAQAAIAA0IFfAAFjwADDQAAQAEAAABgAAAAQAAAJAA AAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBWgV0CAABiAAlAAQACAGIACUhl YWRpbmcgOQAAQAAJAA0JFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACgBVgVaBXQIAYxIAIgBBQPL/oQAiABZEZWZhdWx0IFBhcmFncmFw aCBGb250AAAAAAAAAAAAAABGAENAAQDyAEYAEEJvZHkgVGV4dCBJbmRlbnQAJAAPABFoARbwAA8a AAhoAdACOASgBQgHcAjYCUALQEBAQEBAQEADAF0DAAA6AB9AAQASAToABkhlYWRlcgAhABAAFvAA DxoACGgB0AI4BKAFCAdwCNgJQAsAAAAAAAAAAAADAF0DAAAeAEJAAQASAR4ACUJvZHkgVGV4dAAA BQARABZ4AAAAACAAIEABACIBIAAGRm9vdGVyAAwAEgAPCAAC4BDAIQECAAAYAChAogAxARgAC0xp bmUgTnVtYmVyAAAAAB4AHUABAEIBHgANRm9vdG5vdGUgVGV4dAAAAgAUAAAAIAAmQKIAUQEgABJG b290bm90ZSBSZWZlcmVuY2UAAgBoASwA/k/x/2IBLAALQ2VsbEJvZHlDdHIAAAkAFgAFARQYAQAA AAgAXQQAYQkEYgEqABNAAQACACoABVRPQyAxAAAVABcADxEGaAHQAjgEoAUIB3AIAVggSgAAACwA FEABAAIALAAFVE9DIDIAABgAGAARyAAPEQZoAdACOASgBQgHcAgBWCAKAAAsABVAAQACACwABVRP QyAzAAAYABkAEZABDxEGaAHQAjgEoAUIB3AIAVggCgAALAAWQAEAAgAsAAVUT0MgNAAAGAAaABFY Ag8RBmgB0AI4BKAFCAdwCAFYIAoAACQAF0ABAAIAJAAFVE9DIDUAAA8AGwARIAMPCAACaAFYIEgK AAAAJAAYQAEAAgAkAAVUT0MgNgAADwAcABHoAw8IAAJoAVggSAoAAAAkABlAAQACACQABVRPQyA3 AAAPAB0AEbAEDwgAAmgBWCBICgAAACQAGkABAAIAJAAFVE9DIDgAAA8AHgAReAUPCAACaAFYIEgK AAAAJAAbQAEAAgAkAAVUT0MgOQAADwAfABFABg8IAAJoAVggSAoAAAA6AP5PAQACAjoADFZ0YWJs ZSBlbnRyeQAZACAABQMUEP8AAA8OBmgB0AI4BKAFCAdwCAAABgBdAABhCQg6AP5PAQASAjoAC3N5 bnRheCB0ZXh0AAAeACEABwEIARFoARQQ/wAADw4GaAHQAjgEoAUIB3AIAAIAVYE4AP5PAQAiAjgA DFZ0YWJsZSBpbnRybwAaACIABQMVeAAWeAAPDgZoAdACOASgBQgHcAgAAwBhCQgAAAAAAHwnAAAH AHwqAAAGAP////8GAAQBAQABAAABMgACAAQBYQADAAAAgQAEAAQAowAFAAAA0QAGAAAAAACICAAA kA8AAFgWAADJHAAAHyMAAHwnAAAAABsAAAABABYBAAACAAEAAAADAFcAAAAEAFkAAAAFAAAAAAAA AAAAGgAAAG4AAAB8AAAAiAEAAKwCAADdBAAAIAYAADcGAACTBgAAtwYAALgGAADBBwAAwgcAANsH AAD0BwAADwgAADIIAAA+CAAAVQgAAFYIAABvCAAAiAgAAKMIAADGCAAA0ggAAOkIAADrCAAA7AgA ABIJAABECQAARQkAAPEJAAAQCwAAKwsAAKMMAACkDAAAywwAAOUMAAD9DAAAGQ0AABoNAABMDgAA TQ4AAHwOAACNDgAAGA8AABkPAABGDwAARw8AAIAPAACPDwAAkA8AAJYPAACmEAAA4BAAAIYSAADp EgAAWhMAAFsTAABcEwAAaxMAAK0TAACuEwAA7xMAAA0UAAAqFAAAWhQAAH0UAAB+FAAAfxQAAIkU AADWFQAAKxYAACwWAAAtFgAAWBYAAFkWAABsFgAAsxYAALQWAADgFgAAAxcAAAQXAAASFwAAYhkA AJAZAADfGQAA4BkAAPcZAABDGgAAfhoAAKEaAACiGgAAqhoAACUcAABpHAAAahwAAMccAADIHAAA yRwAANscAAAgHQAAIR0AAGMdAACGHQAAhx0AAJUdAABFHgAARh4AAH4eAACoHgAAux4AAL4eAAD1 HgAA+R4AACcfAABPHwAAch8AAIkfAACKHwAAoh8AAM8fAADnHwAA/R8AABcgAAAYIAAAdSAAAIUg AACJIQAArCEAAMEhAADUIQAA6yEAAOwhAABEIgAAXCIAAHgjAAB5IwAApSMAAL0jAADTIwAA7SMA AO4jAAALJAAAOyQAADwkAAC4JAAAuSQAANkkAADaJAAACiUAABklAABnJQAAaCUAAKElAACiJQAA zyUAANAlAADRJQAA5SUAAI8mAACQJgAAziYAAM8mAAD8JgAA/SYAAP4mAAD/JgAAACcAAAEnAAB8 JwAAFAACAJwADwAkAAMAnAAPAJwADwCcAA8AnAAPACQAAwCcAA8AnAAAAJwAAACcAA8AnAAAAJwA AACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAA AJwADwCcAAAAnAAAAJwADwCcAA8ANAAEAJwADwCcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAA8A nAAAAJwADwA0AAQAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAPADQABACcAA8AnAAPAJwADwCd AAAAnQAAAJwAAACcAAAANAAEAJwADwCcAAAAnQAAAJ0AAACdAAAAnQAAAJ0AAACcAAAAnAAAADQA BACcAA8AnAAPAJwADwCcAAAAnQAAAJwAAAA0AAQAnAAAAJwAAACdAAAAnQAAAJwADwA0AAQAnAAP AJ0AAACdAAAAnAAAADQABACcAA8AnQAAAJ0AAACcAA8ANAAEAJwADwCcAAAAnAAAAJ0AAACcAAAA nAAAADQABACcAAAAnAAAAJ0AAACdAAAAnAAAACQAAwCcAA8AnAAAAJwAAACcAAAAnAAAAJwAAACc AAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAANAAEAJwAAACcAAAAnAAAAJwAAACcAAAAnAAPADQA BACcAA8AnAAAAJwAAACcAAAAnAAAAJwAAACcAA8ANAAEAJwADwCcAAAAnAAAAJwAAACcAAAAnAAA AJwAAACcAA8AnAAAAJwAAACcAA8AnAAAAJwAAACcAAAAnAAPADQABACcAA8AnAAAAJwAAACcAAAA nAAAAJwAAACcAAAANAAEAJwADwCcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACc AAAAAAAAAEAAAAB6AAAAfQAAAAADAACfKgAAFgAAAwAApA8AAFoWAADuFgAAWBkAAI8cAABqHwAA RSEAAFwlAAD8KQAAeyoAAHwqAAAXABgAGQAaABsAHAAdAB4AHwAgACEAfCcAAG8AAAB0AAAAdgAA AH0AAAATIRT/FYBgAQ1fVG9jMzcyOTk3NDUzDV9Ub2MzNzI5OTc0NTQNX1RvYzM2OTU4NDA0Mw1f VG9jMzcyOTk3NDU1DV9Ub2MzNjk1ODQwNDgNX1RvYzM3Mjk5NzQ1Ng1fVG9jMzcyOTk3NDU3DV9U b2MzNzI5OTc0NjkNX1RvYzM3Mjk5NzQ1OA1fVG9jMzcyOTk3NDcyDV9Ub2MzNzI5OTc0NTkNX1Rv YzM3Mjk5NzQ3NQ1fVG9jMzcyOTk3NDYwDV9Ub2MzNzI5OTc0NzgNX1JlZjM2OTU3NTgwMQ1fUmVm MzY5NTc1OTY2DV9Ub2MzNjk1ODQwNTANX1RvYzM3Mjk5NzQ2Mg1fVG9jMzcyOTk3NDYzDV9Ub2Mz NzI5OTc0NjQNX1RvYzM2OTU4NDA1MQ1fUmVmMzY5NTg4NTA4DV9SZWYzNjk1ODg1MjMNX1RvYzM3 Mjk5NzQ2NQ1fVG9jMzcyOTk3NDY2AAAAAG4AAAAgBgAAIAYAABALAAAQCwAAkA8AAFwTAAB/FAAA WRYAAAQXAADgGQAAohoAAMkcAACKHwAAih8AAIofAACKHwAAdSAAAEQiAAAKJQAACiUAAAolAAAK JQAA0SUAAH0nAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA AHsAAAAkBgAANgYAACoLAAAqCwAAlQ8AAGoTAACIFAAAaxYAABEXAAD2GQAAqRoAANocAAChHwAA oR8AAKEfAAChHwAAhCAAAFsiAAAOJQAADiUAAA4lAAAYJQAA5CUAAH0nAAAAAAAAsAQAALQEAABj DwAAbA8AAG8PAAB8DwAAhw8AAI4PAACAEgAAgxIAAOQSAADnEgAAfxQAAIgUAABZFgAAYhYAAAQX AAARFwAAxhkAAM8ZAADgGQAA7RkAAKIaAACpGgAArhwAALccAACMIgAAkCIAAD8lAABCJQAAECYA ABMmAAAAJwAAFCcAABcnAABAJwAARScAAFEnAABhJwAAfScAAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAHAAHABwABwAc AAcATQAKRG9uIFdyaWdodBpEOlxkYXRhXHdvcmRcaXBwXGlwcDkyLmRvYwtyb2dlciBkZWJyeRhF OlxpcHA5Mi1odHRwIHN5bnRheC5kb2P/QE15IFByaW50ZXIATFBUMToAd2luc3Bvb2wATXkgUHJp bnRlcgBNeSBQcmludGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAA AAABAA8ALAECAAEALAECAAAATGV0dGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////8lAwAA AAAAAP//////////AAAAAAAABwABAAMA//8FAAEA//8AAAAAAAD//wAAAAD///////////////// ////AAACAP////////////8AAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAATXkgUHJpbnRlcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAABBAEDnABwAANjAQABAAEAAAAAAAAAAQAPACwBAgABACwBAgAA AExldHRlcgABGgkAAwAMABAAFAAWABgAHAAkADAAPABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAD/////JQMAAAAAAAD//////////wAAAAAA AAcAAQADAP//BQABAP//AAAAAAAA//8AAAAA/////////////////////wAAAgD///////////// AAAAABgAAAAAABAnECcQJwAAECcAAAAAAAAAAAMAAQD/JgAAACcAAAgAAQABAP8mAAAFAAAA/yYA AGIAFRaQAQAAVGltZXMgTmV3IFJvbWFuAAwWkAECAFN5bWJvbAALJpABAABBcmlhbAARNZABAABD b3VyaWVyIE5ldwAeEpABAAhUbXMgUm1uAFRpbWVzIE5ldyBSb21hbgAAIAAEAEAAiAAAANACAABo AQAAAACSqQuGkqkLhpKpC4YCAAAAAACkBQAAKCAAAAYAEAAAAAQAAwBEAAAAXk8AAGXEAQAGAOcA AADFAwAAAAAAACQDAAAAAEMAAAAZUHJvcG9zZWQgSW50ZXJuZXQtRHJhZnQJUwAAAAtyb2dlciBk ZWJyeQtyb2dlciBkZWJyeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAACmAAAA/////z8AVAAAAAoAsAIUALAC FAA1AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AQAAAAAJAgAAAAAAwAAAAAAAAEYAAAAA4I0f m6bXuwEwlUa4sNe7ATUAAACAAwAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAFABAAhQA hgEBAIYBAQCw5hIAAAAAAIEAAACGAQEAeOYSAAAAAAAaAAIBAgAAAAMAAAD/////CwAAAKoAAAAC AAAAwQAAABgAAACGAQEAAAAAANipHQAsAAAANwAAAL1cAAADAAAAAQBDAG8AbQBwAE8AYgBqAAAA AQAAAAAA2KkdACwAAABAAAAAhgEBAAIAAAB0AAAAAgAAAIsAAAAYAAAAhgEBABIAAgH///////// //////+GAQEAAQAAAF0AAAACAAAAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAIYBAQAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAhgEBAAwAAAAfAAAAAgAAADYAAAAY AAAAKAACAf////8EAAAA/////0AAAACGAQEABwAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADUAQAAAAEQAP//////////////////////////////////////////CQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAAD8AAAD//////////////////////////////////////////xkAAAAaAAAA GwAAABwAAAAdAAAAHgAAAB8AAABHAAAA//////////////////////////////////////////// /////////////////////////zEAAAD9/////v///zYAAAD+///////////////+////NAAAAP7/ //84AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAACAAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAA AEYAAAAYAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAA MAAAAP////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////AQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA/v///wsAAAAMAAAA DQAAAP7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////9wAAADAAAAAHEAfBEAAAEAcACMEQAAAwBwAI0RAAAAAHEAnyoAAAAAcQChKgAAAABw AEUSAAAAAHAApSoAAAAAcQCmKgAAAABxAKoqAAAAAHAAsCoAAAAAcQC2KgAAAABxAMgqAAAAAHEA yyoAAAAAcQDMKgAAAABxANcqAAAAAHEA9ioAAAAAcQD8KgAAAABxAAcrAAAAAHEADSsAAAAAcQAT KwAAAABwAFMrAAAAAHAAdCsAAAAAcQB1KwAAAABxAKwrAAAAAHAAsCsAAAAAcACPEgAABQBwAJAS AAAAAHEAsSsAAAAAcQC6KwAAAABxACsUAAAAAHEAvisAAAAAcQC/KwAAAABxACMVAAAAAHEA4BMA AAAAcADAKwAAAABwAIUVAAAAAHAAwSsAAAAAcAChFQAAAABwAM8XAAAAAHEAiRcAAAAAcAAqGQAA AABwAMIrAAAAAHAAjhwAAAAAcADDKwAAAABwAFQdAAAAAHEAxCsAAAAAcAC2HQAAAABwAMgrAAAA AHAAMiAAAAAAcADJKwAAAABwAAAqAAAAAHEAyisAAAAAcAB2KgAAAABwAHoqAAAAAHAAeyoAAAAA YgAVFpABAABUaW1lcyBOZXcgUm9tYW4ADBaQAQIAU3ltYm9sAAsmkAEAAEFyaWFsABE1kAEAAENv dXJpZXIgTgUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACgAAAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAApgAAAP////8/AFQAAAAKALACFACwAhQANQAA AAAAAAAAAAAAAAAAABYABQH//////////wEAAAAACQIAAAAAAMAAAAAAAABGAAAAAOCNH5um17sB kA5FuLDXuwE1AAAAgAMAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAABQAQAIUAIYBAQCG AQEAsOYSAAAAAACBAAAAhgEBAHjmEgAAAAAAGgACAQIAAAADAAAA/////wsAAACqAAAAAgAAAMEA AAAYAAAAhgEBAAAAAADYqR0ALAAAAAAAAAC5WAAAAwAAAAEAQwBvAG0AcABPAGIAagAAAAEAAAAA ANipHQAsAAAAQAAAAIYBAQACAAAAdAAAAAIAAACLAAAAGAAAAIYBAQASAAIB//////////////// hgEBAAEAAABdAAAAAgAAAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAACGAQEABQBTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAIYBAQAMAAAAHwAAAAIAAAA2AAAAGAAAACgA AgH/////BAAAAP////9AAAAAhgEBAAcAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAACAAAA1AEA AAABEAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAc AAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoA AAArAAAALAAAAP7///////////////7//////////v///zEAAAD9/////v///zQAAAD///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////zUAAGNAAAAAAGA0PAIAAABAAAAAAHTdaq7XuwFAAAAAAHTdaq7XuwFAAAAAANQRp7DXuwED AAAABwAAAAMAAADLBQAAAwAAAAghAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cI ACss+a4wAAAAvAAAAAgAAAABAAAASAAAAA8AAABQAAAABAAAAGAAAAAFAAAAaAAAAAYAAABwAAAA CwAAAHgAAAAQAAAAgAAAAAwAAACIAAAAAgAAAOQEAAAeAAAABwAAAE5vdmVsbAAAAwAAAAB2AAAD AAAARgAAAAMAAAAQAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAABoAAABQcm9wb3NlZCBJ bnRlcm5ldC1EcmFmdAlTAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVu dAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYA9DmycQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAACkAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAAxAAAAAQAAADQAAAABQAAAOQAAAAG AAAA8AAAAAcAAAD8AAAACAAAAAwBAAAJAAAAIAEAABIAAAAsAQAACgAAAFQBAAALAAAAYAEAAAwA AABsAQAADQAAAHgBAAAOAAAAhAEAAA8AAACMAQAAEAAAAJQBAAATAAAAnAEAAAIAAADkBAAAHgAA ABoAAABQcm9wb3NlZCBJbnRlcm5ldC1EcmFmdAlTADgAHgAAAAEAAAAAABQAHgAAAAwAAAByb2dl ciBkZWJyeQAeAAAAAQAAAAAAAAMeAAAAAQAAAAAAMAAeAAAABwAAAE5vcm1hbABkHgAAAAwAAABy b2dlciBkZWJyeQAeAAAAAgAAADMAAAAeAAAAHgAAAE1pY3Jvc29mdCBXb3JkIGZvciBXaW5kb3dz IDlldwAeEpABAAhUbXMgUm1uAFRpbWVzIE5ldyBSb21hbgAAIAAEAEEAiAAAANACAABoAQAAAACS qQuGoqkLhpKpC4YDABAAAADLBQAACCEAAAcAEAAAAAQAAwBGAAAAXk8AAGXEAQAHAOcAAADFAwAA AAAAACQDAAAAAEMAAAAZUHJvcG9zZWQgSW50ZXJuZXQtRHJhZnQJUwAAAAtyb2dlciBkZWJyeQty b2dlciBkZWJyeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANylaABj4AkEAAAUAGUAAAAAAAAAAAAAAAADAAB8KgAAvVwAAAAAAAAAAAAAAAAAAAAAAAAQKAAA AAAAAHsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAOgcAAABEAAA6BwAAOksAAAAAAAA6 SwAAAAAAADpLAAAAAAAAOksAAAAAAAA6SwAAFAAAALhMAACEBQAAxEsAAPQAAAA8UgAAAAAAADxS AAAAAAAAPFIAABAAAABMUgAACgAAAFZSAABGAAAAuEwAAAAAAADAWwAAYgAAAJxSAAAEAAAAoFIA ABYAAAC2UgAAAAAAALZSAAAAAAAAtlIAAAAAAAC2UgAAYAEAABZUAADMAAAA4lQAAGgAAACXVgAA AgAAAJlWAAAAAAAAmVYAAAAAAACZVgAAJQAAAL5WAAAMAQAAylcAAAwBAADWWAAAHgAAACJcAABY AAAAelwAAEMAAAD0WAAAzAIAAAAAAAAAAAAAAAAAAAAAAAA6SwAAAAAAAEpVAAAAAAAAAAAWABcA AQALALZSAAAAAAAAtlIAAAAAAAAAAAAAAAAAAAAAAAAAAAAASlUAAAAAAABKVQAAAAAAAPRYAAAA AAAASlYAAAAAAAA6SwAAAAAAADpLAAAAAAAAtlIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFIAAAAA AABKVgAAAAAAAEpWAAAAAAAASlYAAAAAAABKVQAAAAEAADpLAAAAAAAAtlIAAAAAAAA6SwAAAAAA ALZSAAAAAAAAl1YAAAAAAAAAAAAAAAAAADCVRriw17sBTksAACwAAAB6SwAASgAAADpLAAAAAAAA OksAAAAAAAA6SwAAAAAAADpLAAAAAAAASlUAAAAAAACXVgAAAAAAAEpWAABNAAAASlYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElQUCBPcGVyYXRpb25zIFVzaW5nIEhUVFANQWxs IElQUCBvcGVyYXRpb25zIGFyZSBkZWZpbmVkIHVzaW5nIEhUVFAgYXMgdGhlIHVuZGVybHlpbmcg Y29tbXVuaWNhdGlvbiBwcm90b2NvbC4NSFRUUCBPdmVydmlldw1JUFAgaXMgYmFzZWQgb24gdGhl IGV4aXN0aW5nIEhUVFAgc3RhbmRhcmQuICBJUFAgaXMgYSBsaWdodHdlaWdodCBhcHBsaWNhdGlv bi1sZXZlbCBwcm90b2NvbCBkZXNpZ25lZCB3aXRoIHRoZSBJbnRlcm5ldCBpbiBtaW5kLiBJdCBp cyBhIGdlbmVyaWMsIHN0YXRlbGVzcywgb2JqZWN0LW9yaWVudGVkIHByb3RvY29sIHdoaWNoIGNh biBiZSB1c2VkIGZvciBhbnkgdGFzayB0aHJvdWdoIGV4dGVuc2lvbiBvZiBpdHMgcmVxdWVzdCBt ZXRob2RzIChjb21tYW5kcykuICANSFRUUCBhbGxvd3MgYW4gb3Blbi1lbmRlZCBzZXQgb2YgbWV0 aG9kcyB0byBiZSB1c2VkIHRvIGluZGljYXRlIHRoZSBwdXJwb3NlIG9mIGEgcmVxdWVzdC4gSXQg YnVpbGRzIG9uIHRoZSBkaXNjaXBsaW5lIG9mIHJlZmVyZW5jZSBwcm92aWRlZCBieSB0aGUgVW5p Zm9ybSBSZXNvdXJjZSBMb2NhdGlvbiAoVVJMKSBhbmQgbWVzc2FnZSBmb3JtYXRzIHNpbWlsYXIg dG8gdGhvc2UgdXNlZCBieSBJbnRlcm5ldCBNYWlsIGFuZCB0aGUgTXVsdGlwdXJwb3NlIEludGVy bmV0IE1haWwgRXh0ZW5zaW9ucyAoTUlNRSkuDUhUVFAgaXMgYmFzZWQgb24gYSByZXF1ZXN0LXJl c3BvbnNlIHBhcmFkaWdtLiBBIHJlcXVlc3RpbmcgcHJvZ3JhbSAoYSBjbGllbnQpIGVzdGFibGlz aGVzIGEgY29ubmVjdGlvbiB3aXRoIGEgcmVjZWl2aW5nIHByb2dyYW0gKGEgc2VydmVyKSBhbmQg c2VuZHMgYSByZXF1ZXN0IHRvIHRoZSBzZXJ2ZXIgaW4gdGhlIGZvcm0gb2YgYSByZXF1ZXN0IG1l dGhvZCwgYSBVUkwsIGFuZCBwcm90b2NvbCB2ZXJzaW9uLCBmb2xsb3dlZCBieSBhIE1JTUUtbGlr ZSBtZXNzYWdlIGNvbnRhaW5pbmcgcmVxdWVzdCBtb2RpZmllcnMsIGNsaWVudCBpbmZvcm1hdGlv biwgYW5kIHBvc3NpYmx5IHByaW50IGRhdGEuICBUaGUgc2VydmVyIHJlc3BvbmRzIHdpdGggYSBz dGF0dXMgbGluZSwgaW5jbHVkaW5nIGl0cyBwcm90b2NvbCB2ZXJzaW9uLCBhbmQgYSBzdWNjZXNz IG9yIGZhaWx1cmUgY29kZSwgZm9sbG93ZWQgYnkgYSBNSU1FLWxpa2UgbWVzc2FnZSBjb250YWlu aW5nIHNlcnZlciBpbmZvcm1hdGlvbiwgZW50aXR5IG1ldGEtaW5mb3JtYXRpb24sIGFuZCBwb3Nz aWJseSBzb21lIGNvbnRlbnQuDUN1cnJlbnQgcHJhY3RpY2UgcmVxdWlyZXMgdGhhdCB0aGUgY29u bmVjdGlvbiBiZSBlc3RhYmxpc2hlZCBieSB0aGUgY2xpZW50IHByaW9yIHRvIGVhY2ggcmVxdWVz dCBhbmQgY2xvc2VkIGJ5IHRoZSBzZXJ2ZXIgYWZ0ZXIgc2VuZGluZyB0aGUgcmVzcG9uc2UuIEJv dGggY2xpZW50cyBhbmQgc2VydmVycyBtdXN0IGJlIGNhcGFibGUgb2YgaGFuZGxpbmcgY2FzZXMg d2hlcmUgZWl0aGVyIHBhcnR5IGNsb3NlcyB0aGUgY29ubmVjdGlvbiBwcmVtYXR1cmVseSwgZHVl IHRvIHVzZXIgYWN0aW9uLCBhdXRvbWF0ZWQgdGltZSBvdXQsIG9yIHByb2dyYW0gZmFpbHVyZS4N SVBQIE9wZXJhdGlvbiBFbmNvZGluZw1JUFAgbWVzc2FnZXMgY29uc2lzdCBvZiByZXF1ZXN0cyBm cm9tIGNsaWVudCB0byBzZXJ2ZXIgYW5kIHJlc3BvbnNlcyBmcm9tIHNlcnZlciB0byBjbGllbnQu DQkJSFRUUCBNRVNTQUdFID0gUmVxdWVzdCB8IFJlc3BvbnNlDQ1SZXF1ZXN0cyBhbmQgcmVzcG9u c2VzIHVzZSB0aGUgZ2VuZXJpYyBtZXNzYWdlIGZvcm1hdCBvZiBSRkMgODIyIGZvciB0cmFuc2Zl cnJpbmcgZW50aXRpZXMuIEJvdGggbWVzc2FnZXMgbWF5IGluY2x1ZGUgb3B0aW9uYWwgaGVhZGVy IGZpZWxkcyBhbmQgYW4gZW50aXR5IGJvZHkuIFRoZSBlbnRpdHkgYm9keSBpcyBzZXBhcmF0ZWQg ZnJvbSB0aGUgaGVhZGVycyBieSBhIG51bGwgbGluZSAoYSBsaW5lIHdpdGggbm90aGluZyBwcmVj ZWRpbmcgdGhlIENSTEYpLiANDQkJUmVxdWVzdCA9IFJlcXVlc3QtbGluZQ0JCQkgICAgKiAoR2Vu ZXJhbC1IZWFkZXINCQkJICAgIHwgIFJlcXVlc3QtSGVhZGVyICANCSAgICAgICAgICAgICAgICB8 ICBFbnRpdHktSGVhZGVyKQ0JCQkgICAgQ1JMRg0JCQkgICAgWyBFbnRpdHktQm9keSBdDQ0JCVJl c3BvbnNlID0gU3RhdHVzLWxpbmUNCQkJICAgICogKEdlbmVyYWwtSGVhZGVyDQkJCSAgICB8ICBS ZXF1ZXN0LUhlYWRlciAgDQkgICAgICAgICAgICAgICAgfCAgRW50aXR5LUhlYWRlcikNCQkJICAg IENSTEYNCQkJICAgIFsgRW50aXR5LUJvZHkgXQ0gDQ1BbGwgSVBQIGhlYWRlcnMgY29uZm9ybSB0 byB0aGUgc3ludGF4DQkJSVBQIEhlYWRlciA9IGZpZWxkIG5hbWUgkzqUIFtmaWVsZC12YWx1ZV0g Q1JMRi4NDUlQUC8xLjAgZGVmaW5lcyB0aGUgb2N0ZXQgc2VxdWVuY2UgQ1IgTEYgYXMgdGhlIGVu ZC1vZi1saW5lIG1hcmtlciBmb3IgYWxsIHByb3RvY29sIGVsZW1lbnRzIGV4Y2VwdCB0aGUgZW50 aXR5LWJvZHkuIEluIHRoaXMgZG9jdW1lbnQsIHRoZSBzZXF1ZW5jZSBDUiBMRiBpcyBzaG93biBh cyBDUkxGLg1Ob3RlIHRoYXQgSFRUUCAxLjEgZGVmaW5lcyBhIHNsaWdodGx5IGRpZmZlcmVudCBz eW50YXgsIGFsbG93aW5nIGZvciBkeW5hbWljYWxseSBnZW5lcmF0ZWQgbWVzc2FnZXMgdG8gYmUg dHJhbnNtaXR0ZWQuIFRoaXMgd291bGQgYmUgcmVxdWlyZWQgZm9yIGNhc2VzIHN1Y2ggYXMgUEMg ZHJpdmVyIGdlbmVyYXRlZCBQcmludCBPcGVyYXRpb25zLiAgSFRUUCAxLjEgZGVmaW5lcyBhIG1l c3NhZ2UgaGVhZGVyIHdoaWNoIHNwZWNpZmllcyBhIHRyYW5zZmVyIGVuY29kaW5nIGNhbGxlZCCT Y2h1bmtzlC4gDUhUVFAgUmVxdWVzdC1IZWFkZXIgRmllbGRzDUhUVFAgcmVxdWVzdCBoZWFkZXIg ZmllbGRzIGFsbG93IHRoZSBjbGllbnQgdG8gcGFzcyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFi b3V0IHRoZSByZXF1ZXN0LCBhbmQgYWJvdXQgdGhlIGNsaWVudCBpdHNlbGYsIHRvIHRoZSBzZXJ2 ZXIuICBBbGwgaGVhZGVyIGZpZWxkcyBhcmUgb3B0aW9uYWwgYW5kIHdoZW4gdXNlZCBpdCBpcyBh c3N1bWVkIHRoYXQgSVBQIHdvdWxkIHVzZSB0aGVzZSBoZWFkZXJzIGluIGEgc3RhbmRhcmQgd2F5 LiAgSVBQIHJlcXVlc3RzIHdpbGwgYmUgY29tcGxldGVseSBlbmNhcHN1bGF0ZWQgd2l0aGluIHRo ZSBlbnRpdHkgYm9keSBvZiBhbiBIVFRQIHJlcXVlc3QuIFRoZSBIVFRQIEVudGl0eS1IZWFkZXIg aGFzIHRoZSBmb3JtIA0NSFRUUCBFbnRpdHktSGVhZGVyID0JIENvbnRlbnQtRW5jb2RpbmcNCQkJ CQkJCQkgfCBDb250ZW50LUxlbmd0aA0JCQkJCQkJCSB8IENvbnRlbnQtVHlwZQ0JCQkgcGFydCBv ZiB0aGUgR2V0IEpvYnMgUmVzcG9uc2U6DQ1SZXN1bHQgQXR0cmlidXRlcwdBdHRyaWJ1dGUgc2V0 IGNvbnRhaW5pbmcgdGhlIHJldHVybmVkIHJlc3VsdHMuBwdFcnJvcnMHT3B0aW9uYWwgRXJyb3Ig SW5mb3JtYXRpb24HBw1UaGUgUHJpbnQgSm9iDVRoZSBlbnRpdHkgYm9keSBvZiBhIHByaW50IHJl cXVlc3Qgd2lsbCBjb250YWluIGEgUHJpbnQgSm9iLCBhcyBkZWZpbmVkIGJlbG93LiBUaGUgaGVh ZGVycyBkZWZpbmVkIGhlcmUgYXJlIElQUCBoZWFkZXJzLCBidXQgZm9sbG93IHRoZSBzYW1lIHN5 bnRheCBhcyB0aGUgYmFzaWMgSFRUUCBoZWFkZXJzLiANDQkJUHJpbnQgSm9iID0gUHJpbnQtSm9i LU9iamVjdC1IZWFkZXIJCQlzZWN0aW9uICgxLjIuMSkNCQkJCQkJW0pvYiBBdHRyaWJ1dGVzXQkJ CQlzZWN0aW9uICgxLjIuNCkNCQkJCQkJKihEb2N1bWVudHMpDQkJDQlKb2IgQXR0cmlidXRlID0g QXR0cmlidXRlIG5hbWUgOiBBdHRyaWJ1dGUgdmFsdWUgQ1JMRg0JCQkNCURvY3VtZW50ID0JRG9j dW1lbnQtSGVhZGVyCQkJc2VjdGlvbiAoMS4yLjIpDQlbRG9jdW1lbnQgYXR0cmlidXRlc10JCXNl Y3Rpb24gKDEuMi41KQ0JW0NvbnRlbnQtSGVhZGVyCQkJc2VjdGlvbiAoMS4yLjMpDQkJICAgICAJ CSBjb250ZW50XQkJCQkNDVByaW50IEpvYiBPYmplY3QgSGVhZGVyDQkJUHJpbnQtSm9iLU9iamVj dCBIZWFkZXIgPSBDb250ZW50LUVuY29kaW5nDQkJCQkJCSB8IENvbnRlbnQtTGVuZ3RoDQkJCQkJ CSB8IENvbnRlbnQtVHlwZQ0JCQkJCQkgfCBleHRlbnNpb24taGVhZGVyDQ0gQ29udGVudC1UeXBl IGlzIGFsd2F5cyCTSVBQIFByaW50IE9iamVjdJQuIE90aGVyIGhlYWRlciBmaWVsZHMgYXJlIGFz IGRlZmluZWQgZm9yIEhUVFAgMS4wLg1Eb2N1bWVudCBIZWFkZXINVGhlIGRvY3VtZW50IGhlYWRl ciBhbGxvd3MgdGhlIGluc2VydGlvbiBvZiBtdWx0aXBsZSBkb2N1bWVudHMgd2l0aGluIGEgam9i LiBBdCB0aGlzIHBvaW50IG9ubHkgYSBsaW1pdGVkIG51bWJlciBvZiBkb2N1bWVudCBhdHRyaWJ1 dGVzIGFyZSBkZWZpbmVkLiBIb3dldmVyLCB0aGlzIHN0cnVjdHVyZSBhbGxvd3MgdGhlIGFkZGl0 aW9uIG9mIG90aGVyIGF0dHJpYnV0ZXMgd2hpY2ggY2FuIGJlIHNwZWNpZmllZCBvbiBhIGRvY3Vt ZW50IGJvdW5kYXJ5Lg1Eb2N1bWVudCBIZWFkZXIgPQlDb250ZW50LUVuY29kaW5nDQkJCQl8IENv bnRlbnQtTGVuZ3RoDQkJCQl8IENvbnRlbnQtVHlwZQ0JCQkJfCBleHRlbnNpb24taGVhZGVyDQ1D b250ZW50IHR5cGUgaXMgYWx3YXlzIJNJUFAgRG9jdW1lbnSULiBPdGhlciBoZWFkZXIgZmllbGRz IGFyZWEgYXMgZGVmaW5lZCBpbiBIVFRQIDEuMC4NRG9jdW1lbnQtQ29udGVudCBIZWFkZXINVGhl IGRvY3VtZW50LWNvbnRlbnQtaGVhZGVyIHByb3ZpZGVzIGFkZGl0aW9uYWwgbWV0YS1pbmZvcm1h dGlvbiBhYm91dCB0aGUgZG9jdW1lbnQuIFRoZSBkb2N1bWVudCBjb250ZW50IGhlYWRlciBpcyBh biBvcHRpb25hbCBmaWVsZCBhbmQgd291bGQgbm90IGJlIHByZXNlbnQgaWYgdGhlIGRvY3VtZW50 IHdhcyBwb2ludGVkIHRvIGJ5IGEgZG9jdW1lbnQgVVJMIGF0dHJpYnV0ZS4gSXQgaXMgY29tcG9z ZWQgb2YgYSBudW1iZXIgb2YgZG9jdW1lbnQgaGVhZGVyIGZpZWxkcyBhcyBmb2xsb3dzOg0NRG9j dW1lbnQtQ29udGVudC1IZWFkZXIgPQkgQ29udGVudC1FbmNvZGluZw0JCQkJCQkgfCBDb250ZW50 LUxlbmd0aA0JCQkJCQkgfCBDb250ZW50LVR5cGUNCQkJCQkJIHwgZXh0ZW5zaW9uLWhlYWRlcg0N Q29udGVudC1UeXBlIGlzIGRlZmluZWQgYXMgOg0JCUNvbnRlbnQtVHlwZSA9IERhdGEgU3RyZWFt IEZvcm1hdCCTL5QgVmVyc2lvbg0NVGh1cywgZm9yIGV4YW1wbGUsIGlmIHRoZSBkb2N1bWVudCB0 byBiZSBwcmludGVkIHdhcyBhIFBvc3RzY3JpcHQgTGV2ZWwgMiBkb2N1bWVudCwgdGhlIENvbnRl bnQtVHlwZSB3b3VsZCBiZSBzcGVjaWZpZWQgYXM6DQ0JCQlDb250ZW50LVR5cGU6IFBvc3RzY3Jp cHQvMi4wDQ1PdGhlciBoZWFkZXIgZmllbGRzIGFyZSBhcyBkZWZpbmVkIGJ5IEhUVFAgMS4wLg1K b2IgQXR0cmlidXRlcw1Kb2IgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCBpbiBzZWN0aW9uIHh4eC4g IEF0dHJpYnV0ZXMgd2lsbCBhbHdheXMgYmUgc2VudCBhcw0NSm9iLUF0dHJpYnV0ZSA9IGF0dHJp YnV0ZSBuYW1lIJM6lCBBdHRyaWJ1dGUgdmFsdWUgIENSTEYNDUF0dHJpYnV0ZSB2YWx1ZSA9IFZh bHVlIHwgKihWYWx1ZSCTLJQgVmFsdWUpDQ0NRG9jdW1lbnQgQXR0cmlidXRlcw1Eb2N1bWVudCBh dHRyaWJ1dGVzIGFyZSBkZWZpbmVkIGluIHNlY3Rpb24geXl5LiAgQXQgdGhpcyBwb2ludCBhIGxp bWl0ZWQgbnVtYmVyIG9mIGF0dHJpYnV0ZSBtYXkgYmUgc3BlY2lmaWVkIG9uIGEgZG9jdW1lbnQg YmFzaXMuIFRoZSBzeW50YXggZm9yIGEgZG9jdW1lbnQgYXR0cmlidXRlIGlzDQ1Eb2N1bWVudC1B dHRyaWJ1dGUgPSBhdHRyaWJ1dGUgbmFtZSCTOpQgQXR0cmlidXRlIHZhbHVlICBDUkxGDQ1BdHRy aWJ1dGUgdmFsdWUgPSBWYWx1ZSB8ICooVmFsdWUgkyyUIFZhbHVlKQ0NDQ0NSW50ZXJuZXQtRHJh ZnQJSVBQIChWZXIuIDAuOTIgTm92ZW1iZXIgMTgsIDE5OTYpCU5vdmVtYmVyIDE5OTYNDWRlQnJ5 LCBIYXN0aW5ncywgSGVycmlvdCxJc2FhY3NvbgkJCQkJCQkJW1BhZ2UgE1BBR0UUNRVdDQ0NDSEA jgCYAZkKmgEAm7ABpNAvpeA9pggHp3AIqKAFqaAFqgAAICBDUkxGDUlQUCBTdGF0dXMtTGluZQ1U aGUgZmlyc3QgbGluZSBvZiB0aGUgZW50aXR5IGJvZHkgaW4gYW4gSVBQIHJlc3BvbnNlIGlzIHRo ZSBJUFAgU3RhdHVzLUxpbmUuIFRoZSBzdGF0dXMtbGluZSBjb25zaXN0cyBvZiBhIHByb3RvY29s IHZlcnNpb24gZm9sbG93ZWQgYnkgYSBudW1lcmljIHN0YXR1cy1jb2RlIGFuZCBhbiBhc3NvY2lh dGVkIHRleHQgbWVzc2FnZS4NDQlJUFAgU3RhdHVzLUxpbmUgPSBJUFAvMS4wIFN0YXR1cy1Db2Rl ICBSZWFzb24tUGhyYXNlICBDUkxGDU5vdGUgdGhhdCB0aGUgcg0NDQ1UaGlzDQ0zIQCOAJgBmQqa AQCbsAGk0C+l4D2mCAencAiooAWpoAWqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAuQoAAL0KAAA5 CwAAPgsAAEULAADNCwAA0gsAANkLAADpCwAA7AsAAD4MAABFDAAA6wwAAO8MAAAeEAAALBAAAE0R AABZEQAAjxIAAJASAADwIQAA9CEAABkjAAAmIwAAnCgAAKAoAADJKQAAzSkAAAAqAABvKgAAcCoA AHQqAAB1KgAAdioAAHcqAAB7KgAAfCoAAJ8qAAChKgAApSoAAKYqAACqKgAAsCoAALYqAADIKgAA yyoAAMwqAADXKgAA9ioAAPwqAAAHKwAADSsAABMrAABTKwAAdCsAAHUrAACsKwAAsCsAALErAAC6 KwAAvisAAL8rAADAKwAAwSsAAMIrAADDKwAAxCsAAMgrAADJKwAAyisAAMsrAADuKwAAAPsA+PYA +PYA9gD4APgA9gD2APQA+AD2APgA+AAA7wDv7e8AAOsA+PQAAAAAAAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAO3rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAJ1AQADYQAECHUBRAQAAAAAAANdAAACVYEABVWBYxAAB1WBWoFjEAAASAADAAAaAwAAbgMAAHwD AACIBAAArAUAAN0HAAAgCQAANwkAAJMJAAC3CQAAuAkAAMEKAADCCgAA2woAAPQKAAAPCwAAMgsA AD4LAABVCwAAVgsAAG8LAACICwAAowsAAMYLAADSCwAA6QsAAOsLAADsCwAAEgwAAEQMAABFDAAA 8QwAABAOAAArDgAAow8AAKQPAAD+AAFYINgA/AACWCDYAPoAAVgg2AD8AAVYINgA/AAFWCDYAPwA CVgg2AD8AAZYINgA+gABWCDYAPwAAlgg2ADdAAFYINgA3QABWCDYAPwABVgg2ADdAAFYINgA3QAB WCDYAN0AAVgg2ADdAAFYINgA3QABWCDYAN0AAVggsgDdAAFYINgA3QABWCDYAN0AAVgg2ADdAAFY INgA3QABWCDYAN0AAVgg2ADdAAFYILIA3QABWCDYAN0AAVgg6wDdAAFYIOsA/AABWCDYAN0AAVgg 2ADdAAFYILIA/AADWCDYAPwABVgg2ADbAAFYINgA/AAGWCDYAN0AAVgg2AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAAAcAAAMNP8BADgCAAEAFAABAGgBAAAAAAAAtwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAEPAAABAgAk/CkAAP0pAAD+KQAA/ykA AAAqAAA/KgAAQCoAAHkqAAB6KgAAeyoAAL4AAVgg2AB7AAFYINgAvgABWCDYADgAAVgg2AA2AAFY INgANgAAAAAAADYAAlgg2AA2AAAAAAAANgAAAAAAAAAAAAAAAQAAAEIAABFIAzHwADDwAA93ACfI +zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt 0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQgAAEWgBMfAAMPAAD3cAJ8j7MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugX UBm4GiAciB3wHsAhkCRgJzAqAC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAAAx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuo DBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAl7KgAAfCoAAKYqAAC2KgAA dCsAAHUrAACxKwAAwSsAAMIrAADDKwAAxCsAAMkrAADKKwAAvQABWCDYALsAAVgg8AC5AAFYINgA tQADWCDYALUAAVgg2AC1AAFYINgAuwAHWCDYALIAA3YH2ACyAAFBFtgAsgACXwfYALIAAnYH2ACw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA ABgBAAMAABFoAQAAAQQAAAEPAABCAAARSAMx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuo DBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA4AIwAIAAEASwAPAAAAAAAy AABA8f8CADIABk5vcm1hbAAYAAAADxQABmgB0AI4BKAFCAdwCEBAQEBAQAYAXQMAYQkEXgABQAEA 8gBeAAlIZWFkaW5nIDEAAD8AAQAIAQ0BFvAADDQAAAEEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAXQMAaxwAXAACQAEAAgBcAAlIZWFkaW5nIDIAAD8A AgAIAQ0CFvAADDQAAAAEAAABgAAAAQAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAMAXQMAAFgAA0ABAPIAWAAJSGVhZGluZyAzAAA/AAMACAENAxbwAAw0AAEABAAAAYAA AAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABEABAAIAWAAJ SGVhZGluZyA0AAA/AAQACAENBBbwAAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAF4ABUABAAIAXgAJSGVhZGluZyA1AABAAAUADQUV8AAWPAAM NAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAF0C AGMWAF4ABkABAAIAXgAJSGVhZGluZyA2AABAAAYADQYV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAA AAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAFaBYxYAAFwAB0ABAAIAXAAJSGVh ZGluZyA3AABAAAcADQcV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAADAF0CAABeAAhAAQACAF4ACUhlYWRpbmcgOAAAQAAIAA0IFfAAFjwA DDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBW gV0CAABiAAlAAQACAGIACUhlYWRpbmcgOQAAQAAJAA0JFfAAFjwADDQAAQAEAAABgAAAAQAAAJAA AAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBVgVaBXQIAYxIAIgBBQPL/oQAi ABZEZWZhdWx0IFBhcmFncmFwaCBGb250AAAAAAAAAAAAAABGAENAAQDyAEYAEEJvZHkgVGV4dCBJ bmRlbnQAJAAPABFoARbwAA8aAAhoAdACOASgBQgHcAjYCUALQEBAQEBAQEADAF0DAAA6AB9AAQAS AToABkhlYWRlcgAhABAAFvAADxoACGgB0AI4BKAFCAdwCNgJQAsAAAAAAAAAAAADAF0DAAAeAEJA AQASAR4ACUJvZHkgVGV4dAAABQARABZ4AAAAACAAIEABACIBIAAGRm9vdGVyAAwAEgAPCAAC4BDA IQECAAAYAChAogAxARgAC0xpbmUgTnVtYmVyAAAAAB4AHUABAEIBHgANRm9vdG5vdGUgVGV4dAAA AgAUAAAAIAAmQKIAUQEgABJGb290bm90ZSBSZWZlcmVuY2UAAgBoASwA/k/x/2IBLAALQ2VsbEJv ZHlDdHIAAAkAFgAFARQYAQAAAAgAXQQAYQkEYgEqABNAAQACACoABVRPQyAxAAAVABcADxEGaAHQ AjgEoAUIB3AIAVggSgAAACwAFEABAAIALAAFVE9DIDIAABgAGAARyAAPEQZoAdACOASgBQgHcAgB WCAKAAAsABVAAQACACwABVRPQyAzAAAYABkAEZABDxEGaAHQAjgEoAUIB3AIAVggCgAALAAWQAEA AgAsAAVUT0MgNAAAGAAaABFYAg8RBmgB0AI4BKAFCAdwCAFYIAoAACQAF0ABAAIAJAAFVE9DIDUA AA8AGwARIAMPCAACaAFYIEgKAAAAJAAYQAEAAgAkAAVUT0MgNgAADwAcABHoAw8IAAJoAVggSAoA AAAkABlAAQACACQABVRPQyA3AAAPAB0AEbAEDwgAAmgBWCBICgAAACQAGkABAAIAJAAFVE9DIDgA AA8AHgAReAUPCAACaAFYIEgKAAAAJAAbQAEAAgAkAAVUT0MgOQAADwAfABFABg8IAAJoAVggSAoA AAA6AP5PAQACAjoADFZ0YWJsZSBlbnRyeQAZACAABQMUEP8AAA8OBmgB0AI4BKAFCAdwCAAABgBd AABhCQg6AP5PAQASAjoAC3N5bnRheCB0ZXh0AAAeACEABwEIARFoARQQ/wAADw4GaAHQAjgEoAUI B3AIAAIAVYE4AP5PAQAiAjgADFZ0YWJsZSBpbnRybwAaACIABQMVeAAWeAAPDgZoAdACOASgBQgH cAgAAwBhCQgAAAAAAIwoAAAHAMsrAAADAP////8HAAQBAQABAAABMgACAAQAYQADAAAAggAEAAQA ogAFAAIAzgAGAAYA/gAHAAAAAACICAAAlg8AAF4WAABCHAAAmSIAAA8oAACMKAAAAAAbAAAAAQDO AAAAAgBIAAAAAwDyAAAABAAjAAAABQABAAAABgAAAAAAfA4AAI0OAAAZDwAAlQ8AAJYPAACmDwAA ZBAAAGUQAAChEAAAohAAAPIRAACaEwAAmxMAALcTAACfFQAAphYAAJgaAACkGgAAWRsAAGsbAADB GwAAMB4AAEIeAAAPKAAAjCgAAAABWCDYAAADWCDYAAABWCDYAAABWCDwAAABWCDYAAADWCDYAAAB WCDYAAABWCDYAAABWCDYAAABWCDYAAAHWCDYAAABWCDYAAADdgfYAAABdgfYAAAFWCDYAAADWCDY AAABQRbYAAABQRbYAAACXwfYAAABXwfYAAAGWCDYAAACdgfYAAABdgfYAAAAAAAAAAAAAAAaAAAA bgAAAHwAAACIAQAArAIAAN0EAAAgBgAANwYAAJMGAAC3BgAAuAYAAMEHAADCBwAA2wcAAPQHAAAP CAAAMggAAD4IAABVCAAAVggAAG8IAACICAAAowgAAMYIAADSCAAA6QgAAOsIAADsCAAAEgkAAEQJ AABFCQAA8QkAABALAAArCwAAowwAAKQMAADLDAAA5QwAAP0MAAAZDQAAGg0AAEwOAABNDgAAfA4A AI0OAAAYDwAAGQ8AAEwPAABNDwAAhg8AAJUPAACWDwAApg8AAGQQAABlEAAAoRAAAKIQAACoEAAA uBEAAPIRAACaEwAAmxMAAP8TAABwFAAAcRQAAHIUAACBFAAAwxQAAMQUAAAFFQAAIxUAAEAVAABw FQAAkxUAAJQVAACVFQAAnxUAAKYWAABAFwAAQRcAAEIXAABtFwAAbhcAAIEXAADIFwAAyRcAAPUX AAAYGAAAGRgAACcYAAB3GgAAphoAAPUaAAD2GgAADRsAAFkbAACVGwAAuBsAALkbAADBGwAANB0A AHgdAAB5HQAA1h0AANcdAADYHQAA6h0AAC8eAAAwHgAAcx4AAJYeAACXHgAApR4AAFUfAABWHwAA jh8AALgfAADLHwAAzh8AAAUgAAAJIAAANyAAAF8gAACCIAAAmSAAAJogAACyIAAA3yAAAPcgAAAN IQAAJyEAACghAACFIQAAlSEAAJkiAAC8IgAA0SIAAOQiAAD7IgAA/CIAAFQjAABsIwAAiCQAAIkk AAC1JAAAzSQAAOMkAAD9JAAA/iQAABslAABLJQAATCUAAMglAADJJQAA6SUAAOolAAAaJgAAKSYA AHcmAAB4JgAAsSYAALImAADfJgAA4CYAAOEmAAD1JgAAnycAAKAnAADeJwAA3ycAAAwoAAANKAAA DigAAA8oAACMKAAAjCgAABQAAgCcAA8AJAADAJwADwCcAA8AnAAPAJwADwAkAAMAnAAPAJwAAACc AAAAnAAPAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwA AACcAAAAnAAAAJwAAACcAA8AnAAAAJwAAACcAA8AnAAPADQABACcAA8AnAAAAJwAAACcAAAAnAAA AJwAAACcAAAAnAAPAJwAAACcAA8ANAAEAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwADwA0AAQA nAAAAJwAAACcAAAAnAAAADQABACcAA8AnAAPAJwADwCcAA8AnQAAAJ0AAACcAAAAnAAAADQABACc AA8AnAAAAJ0AAACdAAAAnQAAAJ0AAACdAAAAnAAAAJwAAAA0AAQAnAAPAJwADwCcAA8AnAAAAJ0A AACcAAAANAAEAJwAAACcAAAAnQAAAJ0AAACcAA8ANAAEAJwADwCdAAAAnQAAAJwAAAA0AAQAnAAP AJ0AAACdAAAAnAAPADQABACcAA8AnAAAAJwAAACdAAAAnAAAAJwAAAA0AAQAnAAAAJwAAACdAAAA nQAAAJwAAAAkAAMAnAAPAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACc AAAAnAAAADQABACcAAAAnAAAAJwAAACcAAAAnAAAAJwADwA0AAQAnAAPAJwAAACcAAAAnAAAAJwA AACcAAAAnAAPADQABACcAA8AnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAPAJwAAACcAAAAnAAP AJwAAACcAAAAnAAAAJwADwA0AAQAnAAPAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAADQABACcAA8A nAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJ4AAACcAAAAAAAAAEAAAAB6AAAAfQAAAAADAADu KwAAFgAAAwAApA8AAFoWAADuFgAAWBkAAI8cAABqHwAARSEAAFwlAAD8KQAAeyoAAMorAAAXABgA GQAaABsAHAAdAB4AHwAgACEAjCgAAG8AAAB0AAAAdgAAAH0AAAATIRT/FYBgAQ1fVG9jMzcyOTk3 NDUzDV9Ub2MzNzI5OTc0NTQNX1RvYzM2OTU4NDA0Mw1fVG9jMzcyOTk3NDU1DV9Ub2MzNjk1ODQw NDgNX1RvYzM3Mjk5NzQ1Ng1fVG9jMzcyOTk3NDU3DV9Ub2MzNzI5OTc0NjkNX1RvYzM3Mjk5NzQ1 OA1fVG9jMzcyOTk3NDcyDV9Ub2MzNzI5OTc0NTkNX1RvYzM3Mjk5NzQ3NQ1fVG9jMzcyOTk3NDYw DV9Ub2MzNzI5OTc0NzgNX1JlZjM2OTU3NTgwMQ1fUmVmMzY5NTc1OTY2DV9Ub2MzNjk1ODQwNTAN X1RvYzM3Mjk5NzQ2Mg1fVG9jMzcyOTk3NDYzDV9Ub2MzNzI5OTc0NjQNX1RvYzM2OTU4NDA1MQ1f UmVmMzY5NTg4NTA4DV9SZWYzNjk1ODg1MjMNX1RvYzM3Mjk5NzQ2NQ1fVG9jMzcyOTk3NDY2AAAA AG4AAAAgBgAAIAYAABALAAAQCwAAohAAAHIUAACVFQAAbhcAABkYAAD2GgAAuRsAANgdAACaIAAA miAAAJogAACaIAAAhSEAAFQjAAAaJgAAGiYAABomAAAaJgAA4SYAAI0oAAAAAAAAAQAAAAIAAAAD AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEA AAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAAHsAAAAkBgAANgYAACoLAAAqCwAApxAA AIAUAACeFQAAgBcAACYYAAAMGwAAwBsAAOkdAACxIAAAsSAAALEgAACxIAAAlCEAAGsjAAAeJgAA HiYAAB4mAAAoJgAA9CYAAI0oAAAAAAAAsAQAALQEAABpDwAAcg8AAHUPAACCDwAAjQ8AAJQPAACc EAAAoBAAAFQTAABXEwAA+hMAAP0TAACVFQAAnhUAAG4XAAB3FwAAGRgAACYYAADcGgAA5RoAAPYa AAADGwAAuRsAAMAbAAC9HQAAxh0AAJwjAACgIwAATyYAAFImAAAgJwAAIycAABAoAAAkKAAAJygA AFAoAABVKAAAYSgAAHEoAACNKAAABwAcAAcAHAAHABwABwAcAAcABAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAHAAHABwABwAcAAcATQAKRG9uIFdy aWdodBpEOlxkYXRhXHdvcmRcaXBwXGlwcDkyLmRvYwtyb2dlciBkZWJyeRhFOlxpcHA5Mi1odHRw IHN5bnRheC5kb2P/QE15IFByaW50ZXIATFBUMToAd2luc3Bvb2wATXkgUHJpbnRlcgBNeSBQcmlu dGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAABAA8ALAECAAEA LAECAAAATGV0dGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////8lAwAAAAAAAP////////// AAAAAAAABwABAAMA//8FAAEA//8AAAAAAAD//wAAAAD/////////////////////AAACAP////// //////8AAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAATXkgUHJpbnRlcgAAAAAAAAAAAAAAAAAA AAAAAAAAAAABBAEDnABwAANjAQABAAEAAAAAAAAAAQAPACwBAgABACwBAgAAAExldHRlcgABGgkA AwAMABAAFAAWABgAHAAkADAAPABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAIAD/////JQMAAAAAAAD//////////wAAAAAAAAcAAQADAP//BQAB AP//AAAAAAAA//8AAAAA/////////////////////wAAAgD/////////////AAAAABgAAAAAABAn ECcQJwAAECcAAAAAAAAAAAOAAQCgEAAAoBAAAAgAAQABAKAQAAABAAAAAxAAAAEIAGcGXQMAYQkE AQsAAgQAZwZdAwBhCQQBBwACAAARaAFTAqQCAAAAAAAAfA4AAIwOAACNDgAARQ8AAEcPAABLDwAA lQ8AAJYPAACaDwAAoA8AAKYPAAC4DwAAuw8AALwPAADHDwAA5g8AAOwPAAD3DwAA/Q8AAAMQAABD EAAAZBAAAGUQAACcEAAAoBAAAKEQAACiEAAA8hEAAPsRAAD/EQAA9RIAAPYSAAD3EgAAWRMAAJkT AACaEwAAthMAALcTAACfFQAA+hYAAD8XAACjGgAApBoAAGobAABrGwAAwRsAAMUbAABBHgAAQh4A AA8oAAAQKAAAhSgAAIYoAACKKAAAiygAAIwoAAA= --Boundary=_0.0_=5030100002202781-- From ipp-archive Thu Nov 21 10:12:08 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24706 for ipp-outgoing; Thu, 21 Nov 1996 10:10:08 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002202840000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002202840000002*@MHS> To: Cc: Subject: Sample flows Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100002202840" Date: Thu, 21 Nov 1996 10:09:07 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO --Boundary=_0.0_=5030100002202840 Classification: Prologue: Epilogue: Scott, attached is a word file containing example flows using the IPP protocol as described in the updated section 5.1. This can be put into the document as an appendix. I guess if it goes into the appendix, you probably don't need to post it separately to the ftp-site. I am going to work on some "pretty" transparencies of the flows that could be posted later for use in presenting IPP. --Boundary=_0.0_=5030100002202840 Content-Type: application/octet-stream; name="1pp92 flows.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGAAAAAAAAAAA EAAAGgAAAAEAAAD+////AAAAABkAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAAAAAAAAAAwAA4RQAAOAuAAAAAAAAAAAAAAAAAAAAAAAAZREAAAAA AAB7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AADoHAAAAHgAAOgcAADolAAAAAAAAOiUA AAAAAAA6JQAAAAAAADolAAAAAAAAOiUAABQAAACEJQAAxAMAAIQlAAAAAAAASCkAAAAAAABIKQAA AAAAAEgpAAAQAAAAWCkAAAoAAABiKQAAFgAAAIQlAAAAAAAA0y0AAHIAAAB4KQAABAAAAHwpAAAW AAAAkikAAAAAAACSKQAAAAAAAJIpAAAAAAAAkikAAAAAAACSKQAAAAAAAJIpAAAAAAAAdisAAAIA AAB4KwAAAAAAAHgrAAAAAAAAeCsAACUAAACdKwAADAEAAKksAAAMAQAAtS0AAB4AAABFLgAAWAAA AJ0uAABDAAAA0y0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOiUAAAAAAACSKQAAAAAAAAAACwAMAAEA AwCSKQAAAAAAAJIpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJIpAAAAAAAAkikAAAAAAADTLQAAAAAA AAorAAAAAAAAOiUAAAAAAAA6JQAAAAAAAJIpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgpAAAAAAAA CisAAAAAAAAKKwAAAAAAAAorAAAAAAAAkikAAHgBAAA6JQAAAAAAAJIpAAAAAAAAOiUAAAAAAACS KQAAAAAAAHYrAAAAAAAAAAAAAAAAAADQ20dcu9e7AU4lAAAUAAAAYiUAACIAAAA6JQAAAAAAADol AAAAAAAAOiUAAAAAAAA6JQAAAAAAAJIpAAAAAAAAdisAAAAAAAAKKwAAbAAAAAorAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABTYW1wbGUgRmxvd3MNVGhlIGZvbGxvd2luZyBleGFt cGxlcyBpbGx1c3RyYXRlIHR5cGljYWwgZmxvd3MgdXNpbmcgdGhlIElQUCBwcm90b2NvbC4gSW4g dGhlc2UgZXhhbXBsZXMsIHRoZSBJUFAgUHJpbnRlciBvYmplY3QgbmFtZWQgk3ByaW50ZXItMZQg aXMgbG9jYXRlZCBhdCB0aGUgbm9kZSBpZGVudGlmaWVkIGJ5IHRoZSBETlMgbmFtZSCTc29tZS5k b21haW4uY29tlC4gQSBqb2IgVGVtcGxhdGUgaGFzIGJlZW4gZGVmaW5lZCBmb3IgUHJpbnRlci0x IHdoaWNoIGVzdGFibGlzaGVzIHRoZSBwcmludCBkZWZhdWx0cy4NRm9yIGJyZXZpdHkgaW4gdGhl IGZvbGxvd2luZyBmbG93cywgYWxsIG9mIHRoZSBIVFRQIGhlYWRlcnMgYXJlIG5vdCBzaG93bi4g SVBQIGhlYWRlcnMgYXJlIHNob3duIGluIGJvbGQgdHlwZS4gSW50ZXJlc3RpbmcgaGVhZGVyIGZp ZWxkcyBhcmUgc2hvd24gaW4gcGFyZW50aGVzZXMpIENSTEYgc2VxdWVuY2VzIGFyZSBub3Qgc2hv d24uDVF1ZXJ5aW5nIHRoZSBwcmludGVyDQ1DbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHNvbWUuZG9tYWluLmNvbQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKA1Qb3N0IGh0dHA6Ly9zb21lLmRv bWFpbi5jb20vcHJpbnRlci0xICAgaHR0cC8xLjANR2V0QXR0cmlidXRlcyAgSVBQLzEuMA0gICBQ cmludGVyLXN0YXRlIDoNICAgU2lkZXMtc3VwcG9ydGVkIDoNICAgTWVkaWEtc3VwcG9ydGVkIDoN ICAgRG9jdW1lbnQtZm9ybWF0cy1zdXBwb3J0ZWQgOg0NKC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDWh0dHAvMS4wICAyMDEgk0NyZWF0 ZWSUIChhIHJlc3BvbnNlKQ0gICBJUFAvMS4wIHh4eCCTYXR0cmlidXRlIGxpc3QgcmV0dXJuZWSU DSAgIFByaW50ZXItc3RhdGUgOiBydW5uaW5nDSAgIFNpZGVzLXN1cHBvcnRlZCA6IDEtc2lkZWQN ICAgTWVkaWEtc3VwcG9ydGVkIDogaXNvLWE0LXdoaXRlLCBpc28tYjQtd2hpdGUNICAgRG9jdW1l bnQtZm9ybWF0cy1zdXBwb3J0ZWQgOiBQb3N0c2NyaXB0LzIuMA0NDVByaW50IE9wZXJhdGlvbiAt IHdpdGggcHJpbnQgZGF0YSBpbmNsdWRlZA1DbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzb21lLmRvbWFpbi5jb20NLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSgNUG9zdCBodHRwOi8vc29tZS5k b21haW4uY29tL3ByaW50ZXItMSAgaHR0cC8xLjANICAgUHJpbnQgSVBQLzEuMA0gICBQcmludC1K b2ItT2JqZWN0IEhlYWRlcg0gICAgICBKb2ItbmFtZSA6IE15IEpvYg0gICAgICBNZWRpdW0gOiBp c28tYTQtd2hpdGUNCQlOb3RpZmljYXRpb24tZXZlbnRzIDogSm9iLWNvbXBsZXRpb24NCQlOb3Rp ZmljYXRpb24tYWRkcmVzcyA6IGpvZUBwYy5kb21haW4uY29tDSAgIERvY3VtZW50IEhlYWRlcg0g ICAgICBEb2N1bWVudC1uYW1lIDogTGV0dGVyIHRvIE1vbQ0gICBEb2N1bWVudC1Db250ZW50IEhl YWRlciAoY29udGVudCB0eXBlID0gUG9zdHNjcmlwdC8yLjApDSAgICAgIERvY3VtZW50IGluIFBv c3RzY3JpcHQgbGV2ZWwgMiBmb3JtYXQNICAgDQ0oLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NaHR0cC8xLjAgIDIwMCCTYWNjZXB0ZWSU DSAgIElQUC8xLjAgeHh4IJNwcmludCBqb2IgYWNjZXB0ZWQgYW5kIHF1ZXVlZJQNICAgICAgSm9i LUlkZW50aWZpZXIgOiBzb21lLmRvbWFpbi5jb20vcHJpbnRlci0xLzAwMzcNICAgICAgQ3VycmVu dC1qb2Itc3RhdGUgOiBwZW5kaW5nDSAgICAgIFByaW50ZXItc3RhdGUgOiBydW5uaW5nDQ1Qcmlu dCBPcGVyYXRpb24gLSB3aXRoIG5vIGRhdGEgaW5jbHVkZWQgDUNsaWVudCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZS5kb21haW4uY29tDQ0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKA0NUG9zdCBo dHRwOi8vc29tZS5kb21haW4uY29tL3ByaW50ZXItMSAgaHR0cC8xLjANICAgUHJpbnQgSVBQLzEu MA0gICBQcmludC1Kb2ItT2JqZWN0IEhlYWRlcg0gICAgICBKb2ItbmFtZSA6IE15IEpvYg0gICAg ICBNZWRpdW0gOiBpc28tYTQtd2hpdGUNCQlOb3RpZmljYXRpb24tZXZlbnRzIDogSm9iLWNvbXBs ZXRpb24NCQlOb3RpZmljYXRpb24tYWRkcmVzcyA6IGpvZUBzb21lLmRvbWFpbi5jb20NICAgRG9j dW1lbnQgSGVhZGVyDSAgICAgIERvY3VtZW50LW5hbWUgOiBMZXR0ZXIgdG8gTW9tDSAgICAgIERv Y3VtZW50LVVSTCA6IGpvZUBwYy5kb21haW4uY29tL0RvY3MvVG8tbW9tLnBzDSANKC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDWh0dHAv MS4wICAyMDAgk2FjY2VwdGVklA0gICBJUFAvMS4wIHh4eCCTcHJpbnQgam9iIGFjY2VwdGVkIGFu ZCBxdWV1ZWSUDSAgICAgIEpvYi1JZGVudGlmaWVyIDogc29tZS5kb21haW4uY29tL3ByaW50ZXIt MS8wMDM3DSAgICAgIEN1cnJlbnQtam9iLXN0YXRlIDogcGVuZGluZw0gICAgICBQcmludGVyLXN0 YXRlIDogcnVubmluZw0NUXVlcnlpbmcgdGhlIHN0YXRlIG9mIHRoZSBqb2IgLSBubyBhdHRyaWJ1 dGVzIHNwZWNpZmllZCwgc28gYWxsIGpvYiBhdHRyaWJ1dGVzIGFyZSByZXR1cm5lZA1DbGllbnQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNvbWUuZG9tYWluLmNv bQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKA1Qb3N0IGh0dHA6Ly9zb21lLmRvbWFpbi5jb20vcHJpbnRlci0xLzAwMzcgIGh0dHAvMTAs DSAgIEdldEF0dHJpYnV0ZXMgIElQUC8xLjANICAgDSgtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDWh0dHAvMS4wIDIwMSCTQ3JlYXRlZJQg KGEgcmVzcG9uc2UpDSAgIElQUC8xLjAgIHh4eCCTYXRyaWJ1dGUgbGlzdCByZXR1cm5lZJQNICAg Sm9iLU5hbWUgOiBNeSBKb2INICAgSm9iLU9yaWdpbmF0b3IgOiBKb2VAc29tZS5kb21haW4uY29t DSAgIEpvYi1vcmlnaW5hdGluZy1ob3N0IDogcGMuZG9tYWluLmNvbQ0gICBOb3RpZmljYXRpb24t YWRkcmVzcyA6IGpvZUBwYy5kb21haW4uY29tDSAgIEpvYi1sb2NhbGUgOiB4eDp4eDp4eA0gICBD dXJyZW50LWpvYi1zdGF0dXMgOiBwcmludGluZw0gICBQcmludGVyLWFzc2lnbmVkIDogcHJpbnRl ci0xDSAgIFN1Ym1pc3Npb24tdGltZSA6IDEyMTQNICAgTWVkaWEtc2hlZXRzLWNvbXBsZXRlZCA6 IDINDUNhbmNlbGluZyBhIEpvYiANQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNvbWUuZG9tYWluLmNvbQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0oDVBvc3Q6IGh0dHA6Ly9zb21lLmRvbWFpbi5j b20vcHJpbnRlci0xLzAwMzcNICAgQ2FuY2VsSm9iICBJUFAvMS4wDSAgIA0oLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ1odHRwLzEuMCAg MjAwIJNva2F5lA1DdXJyZW50LWpvYi1zdGF0ZSA6IHRlcm1pbmF0aW5nDQ1MaXN0aW5nIGpvYnMg b24gcHJpbnRlci0xLCBvbmx5IHJldHVybiBqb2Igc2l6ZXMuIEpvYnMgYXJlIHJldHVybmVkIGlu IHRoZSBvcmRlciB0aGV5IGFyZSBzY2hlZHVsZWQgZm9yIHByaW50aW5nLiBBIEpvYi1pZGVudGlm aWVyIGF0dHJpYnV0ZSBwcmVjZWVkcyB0aGUgYXR0cmlidXRlcyByZXR1cm5lZCBmb3IgZWFjaCBq b2IgdG8gZGVsaW1pdCBqb2IgYm91bmRhcmllcy4NDUNsaWVudCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNvbWUuZG9tYWluLmNvbQ0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSgNUG9zdCBodHRwLzEu MCBzb21lLmRvbWFpbi5jb20vcHJpbnRlci0xDSAgIEdldEpvYnMgIElQUC8xLjAgDSAgICAgIHRv dGFsLWpvYi1vY3RldHMgOg0NKC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ1odHRwLzEuMCAgMjAxIJNDcmVhdGVklCAoYSByZXNwb25z ZSkNICAgSVBQLzEuMCB4eHggk2NyZWF0ZWQgYW4gYXR0cmlidXRlIGxpc3SUDSAgIEpvYi1pZGVu dGlmaWVyIDogMDAzMw0gICB0b3RhbC1qb2Itb2N0ZXRzIDogNDU2Nw0gICBKb2ItaWRlbnRpZmll ciA6IDAwMzQNICAgdG90YWwtam9iLW9jdGV0cyA6IDEyMzQ1DSAgIEpvYi1pZGVudGlmaWVyIDog MDAzNQ0gICB0b3RhbC1qb2Itb2N0ZXRzIDogMTIzNTYNSW50ZXJuZXQtRHJhZnQJSVBQIChWZXIu IDAuOTIgTm92ZW1iZXIgMTgsIDE5OTYpCU5vdmVtYmVyIDE5OTYNDWRlQnJ5LCBIYXN0aW5ncywg SGVycmlvdCxJc2FhY3NvbgkJCQkJCQkJW1BhZ2UgE1BBR0UUMxVdDQ0NDSEAjgCYAZkKmgEAm7AB pNAvpeA9pggHp3AIqKAFqaAFqgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAH0FAAB+BQAA JQYAACYGAADxBwAA8gcAADQIAABVCAAA2AgAAO4IAAAPCQAARwkAAHIJAAB4CQAAeQkAALUJAAAa CwAAGwsAAF4LAAB/CwAABAwAABoMAABwDAAAcQwAAEQOAABFDgAAmQ4AAJoOAADREAAA0hAAABkR AAAaEQAA4BIAAOESAAA5EwAAOhMAAGUUAADUFAAA1RQAANkUAADaFAAA2xQAANwUAADgFAAA4RQA AAQVAAAA+wD2APsA9AD0APQA9O70APsA9AD0APYA+wD2APsA9gD7APYAAOkA6efpAADlAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACdQEAA2EABAh1 AUQEAAAAAAAKSgMDAN9VgWEABAACVYEACEoDAwDfYQAEAAhKAwMA4GEABC4AAwAADQMAACoEAADr BAAAAAUAAAEFAABDBQAAfwUAALAFAADHBQAA2gUAAO8FAAAEBgAAJAYAACUGAABhBgAAYgYAAIcG AACwBgAAywYAAOgGAAAYBwAARwcAAEgHAABJBwAAdAcAALcHAADzBwAAIwgAADQIAABPCAAAZwgA AIMIAACqCAAA1QgAAOgIAAAMCQAARwkAAHMJAAB3CQAAeAkAALUJAADOCQAA/QkAADMKAAD+AAFY INgA/AAFWCDYAPwAA1gg2AD6AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYIPoA9gABWCDYAPYAAVgg 2AD2AAFYINgA9gABWCDYAPYAAVgg2AD2AAFYINgA9gABWCDYAPYAAVgg+gD2AAFYINgA9gABWCDY APYAAVgg2AD2AAFYINgA9gABWCDYAPYAAVgg2AD2AAFYINgA9gABWCDYAPYAAVgg2AD6AAFYINgA /AABWCDYAPwAAVgg+gD2AAFYINgA9gABWCDYAPYAAVgg6wD2AAFYINgA9gABWCDYAPYAAVgg2AD2 AAFYINgA9gABWCDrAPYAAVgg2AD2AAFYIOsA9gABWCDYAPwAAVgg6wD8AAFYIOsA/AABWCDwAPYA AVgg2AD2AAFYINgA9gABWCDYAAAAAAADDwAWAAAAAAEDAAABDwAAAQEALDMKAABVCgAAcwoAAHQK AACdCgAA3woAAOAKAAAcCwAAHQsAAE0LAABeCwAAeQsAAJELAACtCwAA1AsAAAEMAAAUDAAAOAwA AG4MAABwDAAArQwAAMYMAAD1DAAAKw0AAE0NAABrDQAAbA0AAMgNAAAKDgAARg4AAHsOAACVDgAA mQ4AANUOAAD5DgAAIg8AADcPAABfDwAAhw8AALMPAADMDwAA7Q8AAA0QAAAnEAAARRAAAPwAAVgg 2AD8AAFYINgA/AABWCDYAPoAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg+gD8AAFYINgA/AABWCDY APwAAVgg2AD8AAFYIOsA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg6wD8AAFYINgA /AABWCDYAPwAAVgg2AD4AAFYIPoA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg2AD8 AAFYINgA+gACWCDYAPgAAVgg2AD4AAFYIPoA/AABWCDYAPwAAVgg2AD8AAFYINgA+AABWCD6APwA AVgg2AD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AAB WCDYAPwAAVgg2AD8AAFYINgAAAAAAAAAAAABDwAAAQMAAAMPABYAAAAsRRAAAEYQAABXEAAAmBAA ANMQAAD/EAAAFREAABkRAABUEQAAVREAAGoRAACKEQAAixEAAGESAABiEgAApRIAAOISAAAKEwAA HxMAADgTAAA5EwAAdhMAAHcTAACcEwAAxxMAAOATAAD7EwAAFBQAADAUAABJFAAAZRQAAKQUAACl FAAA3hQAAN8UAADgFAAA4RQAAPwAAVgg2AD6AAFYINgA+AABWCDYAPgAAVgg+gD8AAFYINgA/AAB WCDYAPwAAVgg2AD8AAFYIPoA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPoABFgg2AD4AAFY INgA+AABWCDYAPwAAVgg+gD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCD6APwAAVgg 2AD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA+AABWCDY APYAAVgg2AD2AAAAAAAA9gACWCDYAPYAAAAAAAD2AAAAAAAA+AABWCDYAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEPAAABAwAAAw8AFgAAACQOACMACAABAEsADwAAAAAA MgAAQPH/AgAyAAZOb3JtYWwAGAAAAA8UAAZoAdACOASgBQgHcAhAQEBAQEAGAF0EAGEJBF4AAUAB APIAXgAJSGVhZGluZyAxAAA/AAEACAENARbwAAw0AAABBAAAAYAAAAEAAACQAAAAAAAuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAF0EAGscAFwAAkABAAIAXAAJSGVhZGluZyAyAAA/ AAIACAENAhbwAAw0AAAABAAAAYAAAAEAAACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAADAF0EAABYAANAAQDyAFgACUhlYWRpbmcgMwAAPwADAAgBDQMW8AAMNAABAAQAAAGA AAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAARAAQACAFgA CUhlYWRpbmcgNAAAPwAEAAgBDQQW8AAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABeAAVAAQACAF4ACUhlYWRpbmcgNQAAQAAFAA0FFfAAFjwA DDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBd AgBjFgBeAAZAAQACAF4ACUhlYWRpbmcgNgAAQAAGAA0GFfAAFjwADDQAAQAEAAABgAAAAQAAAJAA AAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBWgWMWAABcAAdAAQACAFwACUhl YWRpbmcgNwAAQAAHAA0HFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwBdAgAAXgAIQAEAAgBeAAlIZWFkaW5nIDgAAEAACAANCBXwABY8 AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUA VoFdAgAAYgAJQAEAAgBiAAlIZWFkaW5nIDkAAEAACQANCRXwABY8AAw0AAEABAAAAYAAAAEAAACQ AAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAVYFWgV0CAGMSACIAQUDy/6EA IgAWRGVmYXVsdCBQYXJhZ3JhcGggRm9udAAAAAAAAAAAAAAARgBDQAEA8gBGABBCb2R5IFRleHQg SW5kZW50ACQADwARaAEW8AAPGgAIaAHQAjgEoAUIB3AI2AlAC0BAQEBAQEBAAwBdBAAAOgAfQAEA EgE6AAZIZWFkZXIAIQAQABbwAA8aAAhoAdACOASgBQgHcAjYCUALAAAAAAAAAAAAAwBdBAAAHgBC QAEAEgEeAAlCb2R5IFRleHQAAAUAEQAWeAAAAAAgACBAAQAiASAABkZvb3RlcgAMABIADwgAAuAQ wCEBAgAAGAAoQKIAMQEYAAtMaW5lIE51bWJlcgAAAAAeAB1AAQBCAR4ADUZvb3Rub3RlIFRleHQA AAIAFAAAACAAJkCiAFEBIAASRm9vdG5vdGUgUmVmZXJlbmNlAAIAaAEsAP5P8f9iASwAC0NlbGxC b2R5Q3RyAAAJABYABQEUGAEAAAAIAF0FAGEJBGIBKgATQAEAAgAqAAVUT0MgMQAAFQAXAA8RBmgB 0AI4BKAFCAdwCAFYIEoAAAAsABRAAQACACwABVRPQyAyAAAYABgAEcgADxEGaAHQAjgEoAUIB3AI AVggCgAALAAVQAEAAgAsAAVUT0MgMwAAGAAZABGQAQ8RBmgB0AI4BKAFCAdwCAFYIAoAACwAFkAB AAIALAAFVE9DIDQAABgAGgARWAIPEQZoAdACOASgBQgHcAgBWCAKAAAkABdAAQACACQABVRPQyA1 AAAPABsAESADDwgAAmgBWCBICgAAACQAGEABAAIAJAAFVE9DIDYAAA8AHAAR6AMPCAACaAFYIEgK AAAAJAAZQAEAAgAkAAVUT0MgNwAADwAdABGwBA8IAAJoAVggSAoAAAAkABpAAQACACQABVRPQyA4 AAAPAB4AEXgFDwgAAmgBWCBICgAAACQAG0ABAAIAJAAFVE9DIDkAAA8AHwARQAYPCAACaAFYIEgK AAAAOgD+TwEAAgI6AAxWdGFibGUgZW50cnkAGQAgAAUDFBD/AAAPDgZoAdACOASgBQgHcAgAAAYA XQAAYQkIOgD+TwEAEgI6AAtzeW50YXggdGV4dAAAHgAhAAcBCAERaAEUEP8AAA8OBmgB0AI4BKAF CAdwCAACAFWBOAD+TwEAIgI4AAxWdGFibGUgaW50cm8AGgAiAAUDFXgAFngADw4GaAHQAjgEoAUI B3AIAAMAYQkIAAAAAADhEQAABADhFAAABQD/////AwAEAQEAAQAAAC8AAgAEAGEAAwAAAAAAeAYA AEYNAADhEQAAAAA9AAAAAQBSAAAAAgAAAAAAAAAAAA0AAAAqAQAA6wEAAAACAAABAgAAQwIAAH8C AACwAgAAxwIAANoCAADvAgAABAMAACQDAAAlAwAAYQMAAGIDAACHAwAAsAMAAMsDAADoAwAAGAQA AEcEAABIBAAASQQAAHQEAAC3BAAA8wQAACMFAAA0BQAATwUAAGcFAACDBQAAqgUAANUFAADoBQAA DAYAAEcGAABzBgAAdwYAAHgGAAC1BgAAzgYAAP0GAAAzBwAAVQcAAHMHAAB0BwAAnQcAAN8HAADg BwAAHAgAAB0IAABNCAAAXggAAHkIAACRCAAArQgAANQIAAABCQAAFAkAADgJAABuCQAAcAkAAK0J AADGCQAA9QkAACsKAABNCgAAawoAAGwKAADICgAACgsAAEYLAAB7CwAAlQsAAJkLAADVCwAA+QsA ACIMAAA3DAAAXwwAAIcMAACzDAAAzAwAAO0MAAANDQAAJw0AAEUNAABGDQAAVw0AAJgNAADTDQAA /w0AABUOAAAZDgAAVA4AAFUOAABqDgAAig4AAIsOAABhDwAAYg8AAKUPAADiDwAAChAAAB8QAAA4 EAAAORAAAHYQAAB3EAAAnBAAAMcQAADgEAAA+xAAABQRAAAwEQAASREAAGURAABmEQAA4REAAAQA AQCcAA8AnAAPACQAAwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAP AJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPACQAAwCcAA8AnAAPAJwADwCcAA8A nAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCc AA8AnAAPAJwADwCcAA8AJAADAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwA DwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwAkAAMAnAAP AJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8A nAAPAJwADwCcAA8AJAADAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwAk AAMAnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwA DwCcAA8AnAAPAJwADwCcAAAAnAAAAAAAAABAAAAAegAAAH0AAAAAAwAABBUAAAsAAAMAADMKAABF EAAA4RQAAAwADQAOAOERAABvAAAAdAAAAHYAAAB9AAAAEyEU/xWAAAAAAMQAAADTAAAAMwIAAEIC AACwAgAAvQIAAJIDAACVAwAApwQAALYEAADDBQAA1AUAANkGAADcBgAAzwcAAN4HAADtCAAAAAkA AE0JAABeCQAAXwkAAGMJAABnCQAAbQkAANEJAADUCQAA+goAAAkLAAB+CwAAiwsAAAUMAAAIDAAA CgwAABIMAABLDAAAXgwAAHkMAACGDAAAoQwAALIMAADDDAAAywwAAIgNAACXDQAAAg4AAAsOAAAY DwAAIA8AAJUPAACkDwAADRAAABQQAACnEAAAqhAAAGURAAB5EQAAfBEAAKURAACqEQAAthEAAMYR AADiEQAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAHABwABwAcAAcAHAAHAGwACkRvbiBXcmlnaHQaRDpcZGF0YVx3b3JkXGlwcFxpcHA5Mi5kb2ML cm9nZXIgZGVicnkYRTpcaXBwOTItaHR0cCBzeW50YXguZG9jC3JvZ2VyIGRlYnJ5EkU6XDFwcDky IGZsb3dzLmRvY/9ATXkgUHJpbnRlcgBMUFQxOgB3aW5zcG9vbABNeSBQcmludGVyAE15IFByaW50 ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBA5wAcAADYwEAAQABAAAAAAAAAAEADwAsAQIAAQAs AQIAAABMZXR0ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA/////yUDAAAAAAAA//////////8A AAAAAAAHAAEAAwD//wUAAQD//wAAAAAAAP//AAAAAP////////////////////8AAAIA//////// /////wAAAAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAABNeSBQcmludGVyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAABAA8ALAECAAEALAECAAAATGV0dGVyAAEaCQAD AAwAEAAUABYAGAAcACQAMAA8AEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAgAP////8lAwAAAAAAAP//////////AAAAAAAABwABAAMA//8FAAEA //8AAAAAAAD//wAAAAD/////////////////////AAACAP////////////8AAAAAGAAAAAAAECcQ JxAnAAAQJwAAAAAAAAAAA4ABAG8JAABvCQAABwAgACAAbwkAAAAAAABvCQAAcgAVFpABAABUaW1l cyBOZXcgUm9tYW4ADBaQAQIAU3ltYm9sAAsmkAEAAEFyaWFsAA8GkAECAFdpbmdkaW5ncwARNZAB AABDb3VyaWVyIE5ldwAeEpABAAhUbXMgUm1uAFRpbWVzIE5ldyBSb21hbgAAIAAEAEAAiAAAANAC AABoAQAAAADyqQuG8qkLhpKpC4YCAAAAAACEAgAAVw4AAAMABwAAAAQAAwAeAAAAXk8AAGXEAQAD AOcAAADFAwAAAAAAACQDAAAAAEMAAAAZUHJvcG9zZWQgSW50ZXJuZXQtRHJhZnQJUwAAAAtyb2dl ciBkZWJyeQtyb2dlciBkZWJyeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAC9 BgAANAAAABkOAABUDgAABwAAAAAAAABnAAAA/////wDAAAAAYAEAFgAFAf//////////AQAAAAAJ AgAAAAAAwAAAAAAAAEYAAAAAoKjBf67XuwGQblyuu9e7ASAAAACAAwAAVQ4AAFcAbwByAGQARABv AGMAdQBtAGUAbgB0AAAAFABAAhQAigEHAIoBBwCw5hIAAAAAAIEAAACKAQcAeOYSAAAAAAAaAAIB AgAAAAMAAAD/////CwAAAKoAAAACAAAAwQAAABgAAACKAQcAAAAAABC3GwAsAAAAGwAAAKgvAAAD AAAAAQBDAG8AbQBwAE8AYgBqAAAABwAAAAAAELcbACwAAABAAAAAigEHAAIAAAB0AAAAAgAAAIsA AAAYAAAAigEHABIAAgH///////////////+KAQcAAQAAAF0AAAACAAAAdAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAagAAAIoBBwAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA igEHAAwAAAAfAAAAAgAAADYAAAAYAAAAKAACAf////8EAAAA/////0AAAACKAQcABwAAAAAAAAAC AAAAAAAAAAAAAAAAAAAAAAAAAAIAAADUAQAAAAEUAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////xwAAAD9/////v///yEAAAD+///////////////+////HwAAACIAAAAjAAAA JAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAy AAAAMwAAADQAAAA1AAAANgAAADcAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////AQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAA/v///wsAAAAMAAAADQAAAP7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////cpWgAY+AJBAAAFABlAAAAAAAAAAAAAAAAAwAA 4RQAAKgvAAAAAAAAAAAAAAAAAAAAAAAALhEAAAAAAAB7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAB4AADoHAAAAHgAAOgcAADolAAAAAAAAOiUAAAAAAAA6JQAAAAAAADolAAAAAAAAOiUAABQA AACcJQAAvAMAAIQlAAAYAAAAWCkAAAAAAABYKQAAAAAAAFgpAAAQAAAAaCkAAAoAAAByKQAAFgAA AJwlAAAAAAAAmy4AAHIAAACIKQAABAAAAIwpAAAWAAAAoikAAAAAAACiKQAAAAAAAKIpAAAAAAAA oikAAAAAAACiKQAAAAAAAKIpAAAAAAAAsSsAAAIAAACzKwAAAAAAALMrAAAAAAAAsysAACUAAADY KwAADAEAAOQsAAAMAQAA8C0AAB4AAAANLwAAWAAAAGUvAABDAAAADi4AAI0AAAAAAAAAAAAAAAAA AAAAAAAAOiUAAAAAAACiKQAAAAAAAAAACwAMAAEAAwCiKQAAAAAAAKIpAAAAAAAAAAAAAAAAAAAA AAAAAAAAAKIpAAAAAAAAoikAAAAAAAAOLgAAAAAAACYrAAAAAAAAOiUAAAAAAAA6JQAAAAAAAKIp AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgpAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQBy AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAvQYAADQA AAAZDgAAVA4AAAcAAAAAAAAAZwAAAP////8AwAAAAGABABYABQH//////////wEAAAAACQIAAAAA AMAAAAAAAABGAAAAAKCowX+u17sBkG5crrvXuwEgAAAAgAMAAFUOAABXAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAABQAQAIUAIoBBwCKAQcAsOYSAAAAAACBAAAAigEHAHjmEgAAAAAAGgACAQIAAAAD AAAA/////wsAAACqAAAAAgAAAMEAAAAYAAAAigEHAAAAAAAQtxsALAAAAAAAAADgLgAAAwAAAAEA QwBvAG0AcABPAGIAagAAAAcAAAAAABC3GwAsAAAAQAAAAIoBBwACAAAAdAAAAAIAAACLAAAAGAAA AIoBBwASAAIB////////////////igEHAAEAAABdAAAAAgAAAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGoAAACKAQcABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAIoBBwAM AAAAHwAAAAIAAAA2AAAAGAAAACgAAgH/////BAAAAP////9AAAAAigEHAAcAAAAAAAAAAgAAAAAA AAAAAAAAAAAAAAAAAAACAAAA1AEAAAABFAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAA AAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA FwAAAP7///////////////7//////////v///xwAAAD9/////v///x8AAAD///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////zUAAVhAAAAAAIyGRwAAAABAAAAAAJwKRbvXuwFAAAAA AJwKRbvXuwFAAAAAACiRjLvXuwEDAAAAAwAAAAMAAAB8AgAAAwAAACoOAAADAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAA AAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAvAAAAAgAAAABAAAASAAAAA8AAABQAAAABAAA AGAAAAAFAAAAaAAAAAYAAABwAAAACwAAAHgAAAAQAAAAgAAAAAwAAACIAAAAAgAAAOQEAAAeAAAA BwAAAE5vdmVsbAAAAwAAAABMAAADAAAAHgAAAAMAAAAHAAAACwAAAAAAAAALAAAAAAAAAAwQAAAC AAAAHgAAABoAAABQcm9wb3NlZCBJbnRlcm5ldC1EcmFmdAlTAAMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAARhgAAABN aWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYA 9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACkAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA xAAAAAQAAADQAAAABQAAAOQAAAAGAAAA8AAAAAcAAAD8AAAACAAAAAwBAAAJAAAAIAEAABIAAAAs AQAACgAAAFQBAAALAAAAYAEAAAwAAABsAQAADQAAAHgBAAAOAAAAhAEAAA8AAACMAQAAEAAAAJQB AAATAAAAnAEAAAIAAADkBAAAHgAAABoAAABQcm9wb3NlZCBJbnRlcm5ldC1EcmFmdAlTAAAAHgAA AAEAAAAAb3JtHgAAAAwAAAByb2dlciBkZWJyeQAeAAAAAQAAAAAAAAAeAAAAAQAAAAAAdAAeAAAA BwAAAE5vcm1hbAAAHgAAAAwAAAByb2dlciBkZWJyeQAeAAAAAgAAADMAAAAeAAAAHgAAAE1pY3Jv c29mdCBXb3JkIGZvciBXaW5kb3dzIDkAACYrAAAAAAAAJisAAAAAAAAmKwAAAAAAAKIpAACEAQAA OiUAAAAAAACiKQAAAAAAADolAAAAAAAAoikAAAAAAACxKwAAAAAAAAAAAAAAAAAAkG5crrvXuwFO JQAAFAAAAGIlAAAiAAAAOiUAAAAAAAA6JQAAAAAAADolAAAAAAAAOiUAAAAAAACiKQAAAAAAALEr AAAAAAAAJisAAIsAAAAmKwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU2FtcGxl IEZsb3dzDVRoZSBmb2xsb3dpbmcgZXhhbXBsZXMgaWxsdXN0cmF0ZSB0eXBpY2FsIGZsb3dzIHVz aW5nIHRoZSBJUFAgcHJvdG9jb2wuIEluIHRoZXNlIGV4YW1wbGVzLCB0aGUgSVBQIFByaW50ZXIg b2JqZWN0IG5hbWVkIJNwcmludGVyLTGUIGlzIGxvY2F0ZWQgYXQgdGhlIG5vZGUgaWRlbnRpZmll ZCBieSB0aGUgRE5TIG5hbWUgk3NvbWUuZG9tYWluLmNvbZQuIEEgam9iIFRlbXBsYXRlIGhhcyBi ZWVuIGRlZmluZWQgZm9yIFByaW50ZXItMSB3aGljaCBlc3RhYmxpc2hlcyB0aGUgcHJpbnQgZGVm YXVsdHMuDUZvciBicmV2aXR5IGluIHRoZSBmb2xsb3dpbmcgZmxvd3MsIGFsbCBvZiB0aGUgSFRU UCBoZWFkZXJzIGFyZSBub3Qgc2hvd24uIElQUCBoZWFkZXJzIGFyZSBzaG93biBpbiBib2xkIHR5 cGUuIEludGVyZXN0aW5nIGhlYWRlciBmaWVsZHMgYXJlIHNob3duIGluIHBhcmVudGhlc2VzKSBD UkxGIHNlcXVlbmNlcyBhcmUgbm90IHNob3duLg1RdWVyeWluZyB0aGUgcHJpbnRlcg0NQ2xpZW50 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21lLmRvbWFpbi5j b20NLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSgNUG9zdCBodHRwOi8vc29tZS5kb21haW4uY29tL3ByaW50ZXItMSAgIGh0dHAvMS4wDUdl dEF0dHJpYnV0ZXMgIElQUC8xLjANICAgUHJpbnRlci1zdGF0ZSA6DSAgIFNpZGVzLXN1cHBvcnRl ZCA6DSAgIE1lZGlhLXN1cHBvcnRlZCA6DSAgIERvY3VtZW50LWZvcm1hdHMtc3VwcG9ydGVkIDoN DSgtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQ1odHRwLzEuMCAgMjAxIJNDcmVhdGVklCAoYSByZXNwb25zZSkNICAgSVBQLzEuMCB4eHgg k2F0dHJpYnV0ZSBsaXN0IHJldHVybmVklA0gICBQcmludGVyLXN0YXRlIDogcnVubmluZw0gICBT aWRlcy1zdXBwb3J0ZWQgOiAxLXNpZGVkDSAgIE1lZGlhLXN1cHBvcnRlZCA6IGlzby1hNC13aGl0 ZSwgaXNvLWI0LXdoaXRlDSAgIERvY3VtZW50LWZvcm1hdHMtc3VwcG9ydGVkIDogUG9zdHNjcmlw dC8yLjANDQ1QcmludCBPcGVyYXRpb24gLSB3aXRoIHByaW50IGRhdGEgaW5jbHVkZWQNQ2xpZW50 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZS5kb21haW4u Y29tDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0oDVBvc3QgaHR0cDovL3NvbWUuZG9tYWluLmNvbS9wcmludGVyLTEgIGh0dHAvMS4wDSAg IFByaW50IElQUC8xLjANICAgUHJpbnQtSm9iLU9iamVjdCBIZWFkZXINICAgICAgSm9iLW5hbWUg OiBNeSBKb2INICAgICAgTWVkaXVtIDogaXNvLWE0LXdoaXRlDQkJTm90aWZpY2F0aW9uLWV2ZW50 cyA6IEpvYi1jb21wbGV0aW9uDQkJTm90aWZpY2F0aW9uLWFkZHJlc3MgOiBqb2VAcGMuZG9tYWlu LmNvbQ0gICBEb2N1bWVudCBIZWFkZXINICAgICAgRG9jdW1lbnQtbmFtZSA6IExldHRlciB0byBN b20NICAgRG9jdW1lbnQtQ29udGVudCBIZWFkZXIgKGNvbnRlbnQgdHlwZSA9IFBvc3RzY3JpcHQv Mi4wKQ0gICAgICBEb2N1bWVudCBpbiBQb3N0c2NyaXB0IGxldmVsIDIgZm9ybWF0DSAgIA0NKC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DWh0dHAvMS4wICAyMDAgk2FjY2VwdGVklA0gICBJUFAvMS4wIHh4eCCTcHJpbnQgam9iIGFjY2Vw dGVkIGFuZCBxdWV1ZWSUDSAgICAgIEpvYi1JZGVudGlmaWVyIDogc29tZS5kb21haW4uY29tL3By aW50ZXItMS8wMDM3DSAgICAgIEN1cnJlbnQtam9iLXN0YXRlIDogcGVuZGluZw0gICAgICBQcmlu dGVyLXN0YXRlIDogcnVubmluZw0NUHJpbnQgT3BlcmF0aW9uIC0gd2l0aCBubyBkYXRhIGluY2x1 ZGVkIA1DbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNv bWUuZG9tYWluLmNvbQ0NLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSgNDVBvc3QgaHR0cDovL3NvbWUuZG9tYWluLmNvbS9wcmludGVyLTEg IGh0dHAvMS4wDSAgIFByaW50IElQUC8xLjANICAgUHJpbnQtSm9iLU9iamVjdCBIZWFkZXINICAg ICAgSm9iLW5hbWUgOiBNeSBKb2INICAgICAgTWVkaXVtIDogaXNvLWE0LXdoaXRlDQkJTm90aWZp Y2F0aW9uLWV2ZW50cyA6IEpvYi1jb21wbGV0aW9uDQkJTm90aWZpY2F0aW9uLWFkZHJlc3MgOiBq b2VAc29tZS5kb21haW4uY29tDSAgIERvY3VtZW50IEhlYWRlcg0gICAgICBEb2N1bWVudC1uYW1l IDogTGV0dGVyIHRvIE1vbQ0gICAgICBEb2N1bWVudC1VUkwgOiBqb2VAcGMuZG9tYWluLmNvbS9E b2NzL1RvLW1vbS5wcw0gDSgtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ1odHRwLzEuMCAgMjAwIJNhY2NlcHRlZJQNICAgSVBQLzEuMCB4 eHggk3ByaW50IGpvYiBhY2NlcHRlZCBhbmQgcXVldWVklA0gICAgICBKb2ItSWRlbnRpZmllciA6 IHNvbWUuZG9tYWluLmNvbS9wcmludGVyLTEvMDAzNw0gICAgICBDdXJyZW50LWpvYi1zdGF0ZSA6 IHBlbmRpbmcNICAgICAgUHJpbnRlci1zdGF0ZSA6IHJ1bm5pbmcNDVF1ZXJ5aW5nIHRoZSBzdGF0 ZSBvZiB0aGUgam9iIC0gbm8gYXR0cmlidXRlcyBzcGVjaWZpZWQsIHNvIGFsbCBqb2IgYXR0cmli dXRlcyBhcmUgcmV0dXJuZWQNQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzb21lLmRvbWFpbi5jb20NLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSgNUG9zdCBodHRwOi8vc29tZS5kb21haW4uY29t L3ByaW50ZXItMS8wMDM3ICBodHRwLzEwLA0gICBHZXRBdHRyaWJ1dGVzICBJUFAvMS4wDSAgIA0o LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ1odHRwLzEuMCAyMDEgk0NyZWF0ZWSUIChhIHJlc3BvbnNlKQ0gICBJUFAvMS4wICB4eHggk2F0 cmlidXRlIGxpc3QgcmV0dXJuZWSUDSAgIEpvYi1OYW1lIDogTXkgSm9iDSAgIEpvYi1PcmlnaW5h dG9yIDogSm9lQHNvbWUuZG9tYWluLmNvbQ0gICBKb2Itb3JpZ2luYXRpbmctaG9zdCA6IHBjLmRv bWFpbi5jb20NICAgTm90aWZpY2F0aW9uLWFkZHJlc3MgOiBqb2VAcGMuZG9tYWluLmNvbQ0gICBK b2ItbG9jYWxlIDogeHg6eHg6eHgNICAgQ3VycmVudC1qb2Itc3RhdHVzIDogcHJpbnRpbmcNICAg UHJpbnRlci1hc3NpZ25lZCA6IHByaW50ZXItMQ0gICBTdWJtaXNzaW9uLXRpbWUgOiAxMjE0DSAg IE1lZGlhLXNoZWV0cy1jb21wbGV0ZWQgOiAyDQ1DYW5jZWxpbmcgYSBKb2IgDUNsaWVudCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21lLmRvbWFpbi5jb20NLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKA1Q b3N0OiBodHRwOi8vc29tZS5kb21haW4uY29tL3ByaW50ZXItMS8wMDM3DSAgIENhbmNlbEpvYiAg SVBQLzEuMA0gICANKC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0NaHR0cC8xLjAgIDIwMCCTb2theZQNQ3VycmVudC1qb2Itc3RhdGUgOiB0 ZXJtaW5hdGluZw0NTGlzdGluZyBqb2JzIG9uIHByaW50ZXItMSwgb25seSByZXR1cm4gam9iIHNp emVzLiBKb2JzIGFyZSByZXR1cm5lZCBpbiB0aGUgb3JkZXIgdGhleSBhcmUgc2NoZWR1bGVkIGZv ciBwcmludGluZy4gQSBKb2ItaWRlbnRpZmllciBhdHRyaWJ1dGUgcHJlY2VlZHMgdGhlIGF0dHJp YnV0ZXMgcmV0dXJuZWQgZm9yIGVhY2ggam9iIHRvIGRlbGltaXQgam9iIGJvdW5kYXJpZXMuDQ1D bGllbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21lLmRv bWFpbi5jb20NLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0oDVBvc3QgaHR0cC8xLjAgc29tZS5kb21haW4uY29tL3ByaW50ZXItMQ0gICBH ZXRKb2JzICBJUFAvMS4wIA0gICAgICB0b3RhbC1qb2Itb2N0ZXRzIDoNDSgtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0NaHR0cC8xLjAg IDIwMSCTQ3JlYXRlZJQgKGEgcmVzcG9uc2UpDSAgIElQUC8xLjAgeHh4IJNjcmVhdGVkIGFuIGF0 dHJpYnV0ZSBsaXN0lA0gICBKb2ItaWRlbnRpZmllciA6IDAwMzMNICAgdG90YWwtam9iLW9jdGV0 cyA6IDQ1NjcNICAgSm9iLWlkZW50aWZpZXIgOiAwMDM0DSAgIHRvdGFsLWpvYi1vY3RldHMgOiAx MjM0NQ0gICBKb2ItaWRlbnRpZmllciA6IDAwMzUNICAgdG90YWwtam9iLW9jdGV0cyA6IDEyMzU2 DUludGVybmV0LURyYWZ0CUlQUCAoVmVyLiAwLjkyIE5vdmVtYmVyIDE4LCAxOTk2KQlOb3ZlbWJl ciAxOTk2DQ1kZUJyeSwgSGFzdGluZ3MsIEhlcnJpb3QsSXNhYWNzb24JCQkJCQkJCVtQYWdlIBNQ QUdFFDMVXQ0NDQ0hAI4AmAGZCpoBAJuwAaTQL6XgPaYIB6dwCKigBamgBaoAAG5vbmUNMQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAADAAB9BQAAfgUAACUGAAAmBgAA8QcAAPIHAAA0CAAAVQgAANgIAADuCAAA DwkAAEcJAAByCQAAeAkAAHkJAAC1CQAAGgsAABsLAABeCwAAfwsAAAQMAAAaDAAAcAwAAHEMAABE DgAARQ4AAJkOAACaDgAA0RAAANIQAAAZEQAAGhEAAOASAADhEgAAORMAADoTAABlFAAA1BQAANUU AADZFAAA2hQAANsUAADcFAAA4BQAAOEUAAAEFQAACBUAAAkVAAAKFQAAAPsA9gD7APQA9AD0APTu 9AD7APQA9AD2APsA9gD7APYA+wD2AADpAOnn6QAA5QAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAnUBAANhAAQIdQFEBAAAAAAACkoDAwDfVYFhAAQAAlWBAAhKAwMA32EA BAAISgMDAOBhAAQxAAMAAA0DAAAqBAAA6wQAAAAFAAABBQAAQwUAAH8FAACwBQAAxwUAANoFAADv BQAABAYAACQGAAAlBgAAYQYAAGIGAACHBgAAsAYAAMsGAADoBgAAGAcAAEcHAABIBwAASQcAAHQH AAC3BwAA8wcAACMIAAA0CAAATwgAAGcIAACDCAAAqggAANUIAADoCAAADAkAAEcJAABzCQAAdwkA AHgJAAC1CQAAzgkAAP0JAAAzCgAA/gABWCDYAPwABVgg2AD8AANYINgA+gABWCDYAPwAAVgg2AD8 AAFYINgA/AABWCD6APYAAVgg2AD2AAFYINgA9gABWCDYAPYAAVgg2AD2AAFYINgA9gABWCDYAPYA AVgg2AD2AAFYIPoA9gABWCDYAPYAAVgg2AD2AAFYINgA9gABWCDYAPYAAVgg2AD2AAFYINgA9gAB WCDYAPYAAVgg2AD2AAFYINgA+gABWCDYAPwAAVgg2AD8AAFYIPoA9gABWCDYAPYAAVgg2AD2AAFY IOsA9gABWCDYAPYAAVgg2AD2AAFYINgA9gABWCDYAPYAAVgg6wD2AAFYINgA9gABWCDrAPYAAVgg 2AD8AAFYIOsA/AABWCDrAPwAAVgg8AD2AAFYINgA9gABWCDYAPYAAVgg2AAAAAAAAw8AFgAAAAAB AwAAAQ8AAAEBACwzCgAAVQoAAHMKAAB0CgAAnQoAAN8KAADgCgAAHAsAAB0LAABNCwAAXgsAAHkL AACRCwAArQsAANQLAAABDAAAFAwAADgMAABuDAAAcAwAAK0MAADGDAAA9QwAACsNAABNDQAAaw0A AGwNAADIDQAACg4AAEYOAAB7DgAAlQ4AAJkOAADVDgAA+Q4AACIPAAA3DwAAXw8AAIcPAACzDwAA zA8AAO0PAAANEAAAJxAAAEUQAAD8AAFYINgA/AABWCDYAPwAAVgg2AD6AAFYINgA/AABWCDYAPwA AVgg2AD8AAFYIPoA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDrAPwAAVgg2AD8AAFYINgA/AAB WCDYAPwAAVgg2AD8AAFYIOsA/AABWCDYAPwAAVgg2AD8AAFYINgA+AABWCD6APwAAVgg2AD8AAFY INgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPoAAlgg2AD4AAFYINgA+AABWCD6APwAAVgg 2AD8AAFYINgA/AABWCDYAPgAAVgg+gD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDY APwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAAAAAAAAAAAAAQ8AAAED AAADDwAWAAAALEUQAABGEAAAVxAAAJgQAADTEAAA/xAAABURAAAZEQAAVBEAAFURAABqEQAAihEA AIsRAABhEgAAYhIAAKUSAADiEgAAChMAAB8TAAA4EwAAORMAAHYTAAB3EwAAnBMAAMcTAADgEwAA +xMAABQUAAAwFAAASRQAAGUUAACkFAAApRQAAN4UAADfFAAA4BQAAOEUAAAJFQAA/AABWCDYAPoA AVgg2AD4AAFYINgA+AABWCD6APwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg+gD8AAFYINgA/AAB WCDYAPwAAVgg2AD8AAFYINgA+gAEWCDYAPgAAVgg2AD4AAFYINgA/AABWCD6APwAAVgg2AD8AAFY INgA/AABWCDYAPwAAVgg2AD8AAFYIPoA/AABWCDYAPwAAVgg2AD8AAFYINgA/AABWCDYAPwAAVgg 2AD8AAFYINgA/AABWCDYAPwAAVgg2AD4AAFYINgA9gABWCDYAPYAAAAAAAD2AAJYINgA9gAAAAAA APYAAAAAAAD4AAFYINgA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABDwAAAQMA AAMPABYAAAAlDgAjAAgAAQBLAA8AAAAAADIAAEDx/wIAMgAGTm9ybWFsABgAAAAPFAAGaAHQAjgE oAUIB3AIQEBAQEBABgBdBABhCQReAAFAAQDyAF4ACUhlYWRpbmcgMQAAPwABAAgBDQEW8AAMNAAA AQQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBdBABr HABcAAJAAQACAFwACUhlYWRpbmcgMgAAPwACAAgBDQIW8AAMNAAAAAQAAAGAAAABAAAAkAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwBdBAAAWAADQAEA8gBYAAlIZWFkaW5n IDMAAD8AAwAIAQ0DFvAADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAWAAEQAEAAgBYAAlIZWFkaW5nIDQAAD8ABAAIAQ0EFvAADDQAAQAEAAAB gAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXgAFQAEAAgBe AAlIZWFkaW5nIDUAAEAABQANBRXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAXQIAYxYAXgAGQAEAAgBeAAlIZWFkaW5nIDYAAEAABgAN BhXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAUAVoFjFgAAXAAHQAEAAgBcAAlIZWFkaW5nIDcAAEAABwANBxXwABY8AAw0AAEABAAAAYAA AAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAXQIAAF4ACEABAAIA XgAJSGVhZGluZyA4AABAAAgADQgV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAFaBXQIAAGIACUABAAIAYgAJSGVhZGluZyA5AABAAAkA DQkV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKAFWBVoFdAgBjEgAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQAAAAAAAAA AAAAAEYAQ0ABAPIARgAQQm9keSBUZXh0IEluZGVudAAkAA8AEWgBFvAADxoACGgB0AI4BKAFCAdw CNgJQAtAQEBAQEBAQAMAXQQAADoAH0ABABIBOgAGSGVhZGVyACEAEAAW8AAPGgAIaAHQAjgEoAUI B3AI2AlACwAAAAAAAAAAAAMAXQQAAB4AQkABABIBHgAJQm9keSBUZXh0AAAFABEAFngAAAAAIAAg QAEAIgEgAAZGb290ZXIADAASAA8IAALgEMAhAQIAABgAKECiADEBGAALTGluZSBOdW1iZXIAAAAA HgAdQAEAQgEeAA1Gb290bm90ZSBUZXh0AAACABQAAAAgACZAogBRASAAEkZvb3Rub3RlIFJlZmVy ZW5jZQACAGgBLAD+T/H/YgEsAAtDZWxsQm9keUN0cgAACQAWAAUBFBgBAAAACABdBQBhCQRiASoA E0ABAAIAKgAFVE9DIDEAABUAFwAPEQZoAdACOASgBQgHcAgBWCBKAAAALAAUQAEAAgAsAAVUT0Mg MgAAGAAYABHIAA8RBmgB0AI4BKAFCAdwCAFYIAoAACwAFUABAAIALAAFVE9DIDMAABgAGQARkAEP EQZoAdACOASgBQgHcAgBWCAKAAAsABZAAQACACwABVRPQyA0AAAYABoAEVgCDxEGaAHQAjgEoAUI B3AIAVggCgAAJAAXQAEAAgAkAAVUT0MgNQAADwAbABEgAw8IAAJoAVggSAoAAAAkABhAAQACACQA BVRPQyA2AAAPABwAEegDDwgAAmgBWCBICgAAACQAGUABAAIAJAAFVE9DIDcAAA8AHQARsAQPCAAC aAFYIEgKAAAAJAAaQAEAAgAkAAVUT0MgOAAADwAeABF4BQ8IAAJoAVggSAoAAAAkABtAAQACACQA BVRPQyA5AAAPAB8AEUAGDwgAAmgBWCBICgAAADoA/k8BAAICOgAMVnRhYmxlIGVudHJ5ABkAIAAF AxQQ/wAADw4GaAHQAjgEoAUIB3AIAAAGAF0AAGEJCDoA/k8BABICOgALc3ludGF4IHRleHQAAB4A IQAHAQgBEWgBFBD/AAAPDgZoAdACOASgBQgHcAgAAgBVgTgA/k8BACICOAAMVnRhYmxlIGludHJv ABoAIgAFAxV4ABZ4AA8OBmgB0AI4BKAFCAdwCAADAGEJCAAAAAAAqhEAAAQA4RQAAAQA/////wMA BAEBAAEAAAAvAAIABgBhAAMAAAAAAEEGAAAPDQAAqhEAAAAAPQAAAAEAUgAAAAIAAAAAACoBAAAS EQAAqhEAAAADWCDYAAAAAAAAAAAAAAANAAAAKgEAALQBAADJAQAAygEAAAwCAABIAgAAeQIAAJAC AACjAgAAuAIAAM0CAADtAgAA7gIAACoDAAArAwAAUAMAAHkDAACUAwAAsQMAAOEDAAAQBAAAEQQA ABIEAAA9BAAAgAQAALwEAADsBAAA/QQAABgFAAAwBQAATAUAAHMFAACeBQAAsQUAANUFAAAQBgAA PAYAAEAGAABBBgAAfgYAAJcGAADGBgAA/AYAAB4HAAA8BwAAPQcAAGYHAACoBwAAqQcAAOUHAADm BwAAFggAACcIAABCCAAAWggAAHYIAACdCAAAyggAAN0IAAABCQAANwkAADkJAAB2CQAAjwkAAL4J AAD0CQAAFgoAADQKAAA1CgAAkQoAANMKAAAPCwAARAsAAF4LAABiCwAAngsAAMILAADrCwAAAAwA ACgMAABQDAAAfAwAAJUMAAC2DAAA1gwAAPAMAAAODQAADw0AACANAABhDQAAnA0AAMgNAADeDQAA 4g0AAB0OAAAeDgAAMw4AAFMOAABUDgAAKg8AACsPAABuDwAAqw8AANMPAADoDwAAARAAAAIQAAA/ EAAAQBAAAGUQAACQEAAAqRAAAMQQAADdEAAA+RAAABIRAACqEQAAqhEAAAQAAQCcAA8AnAAPACQA AwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAP AJwADwCcAA8AnAAPAJwADwCcAA8AnAAPACQAAwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8A nAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCc AA8AJAADAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwA DwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwAkAAMAnAAPAJwADwCcAA8AnAAP AJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8A JAADAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwAkAAMAnAAPAJwADwCc AA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJwADwCcAA8AnAAPAJ4A DwCcAAAAAAAAAEAAAAB6AAAAfQAAAAADAAAKFQAACwAAAwAAMwoAAEUQAAAJFQAADAANAA4AqhEA AG8AAAB0AAAAdgAAAH0AAAATIRT/FYAAAAAAxAAAANMAAACWAQAAmgEAAPwBAAALAgAAeQIAAIYC AABbAwAAXgMAAHAEAAB/BAAAjAUAAJ0FAACiBgAApQYAAJgHAACnBwAAtggAAMkIAAAWCQAAJwkA ACgJAAAsCQAAMAkAADYJAACaCQAAnQkAAMMKAADSCgAARwsAAFQLAADOCwAA0QsAANMLAADbCwAA FAwAACcMAABCDAAATwwAAGoMAAB7DAAAjAwAAJQMAABRDQAAYA0AAMsNAADUDQAA4Q4AAOkOAABe DwAAbQ8AANYPAADdDwAAcBAAAHMQAAAuEQAAQhEAAEURAABuEQAAcxEAAH8RAACPEQAAqxEAAAcA HAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcA HAAHABwABwAcAAcAiwAKRG9uIFdyaWdodBpEOlxkYXRhXHdvcmRcaXBwXGlwcDkyLmRvYwtyb2dl ciBkZWJyeRhFOlxpcHA5Mi1odHRwIHN5bnRheC5kb2MLcm9nZXIgZGVicnkSRTpcMXBwOTIgZmxv d3MuZG9jC3JvZ2VyIGRlYnJ5EkU6XDFwcDkyIGZsb3dzLmRvY/9ATXkgUHJpbnRlcgBMUFQxOgB3 aW5zcG9vbABNeSBQcmludGVyAE15IFByaW50ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBA5wA cAADYwEAAQABAAAAAAAAAAEADwAsAQIAAQAsAQIAAABMZXR0ZXIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACAA/////yUDAAAAAAAA//////////8AAAAAAAAHAAEAAwD//wUAAQD//wAAAAAAAP//AAAA AP////////////////////8AAAIA/////////////wAAAAAYAAAAAAAQJxAnECcAABAnAAAAAAAA AABNeSBQcmludGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAAB AA8ALAECAAEALAECAAAATGV0dGVyAAEaCQADAAwAEAAUABYAGAAcACQAMAA8AEgAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////8lAwAAAAAA AP//////////AAAAAAAABwABAAMA//8FAAEA//8AAAAAAAD//wAAAAD///////////////////// AAACAP////////////8AAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAAYABAJYBAACWAQAABwAB AAEAlgEAAAAAAACWAQAAAogAAAAAAAAATgEAAFIBAABrAQAAlgEAAC0RAAAuEQAAoxEAAKQRAACo EQAAqREAAKoRAABAAAADAAAAAEEABBUAAAAAQQBRBAAAAABBAG4EAAAAAEAAzQQAAAAAQAAIFQAA AABAAGUUAAAAAEEACRUAAAAAQADbFAAAAABAAN8UAAAAAEAA4BQAAAAAcgAVFpABAABUaW1lcyBO ZXcgUm9tYW4ADBaQAQIAU3ltYm9sAAsmkAEAAEFyaWFsAA8GkAECAFdpbmdkaW5ncwARNZABAABD b3VyaWVyIE5ldwAeEpABAAhUbXMgUm1uAFRpbWVzIE5ldyBSb21hbgAAIAAEAEEAiAAAANACAABo AQAAAADyqQuG9KkLhvKpC4YDAAIAAAB8AgAAKg4AAAMABwAAAAQAAwAeAAAAXk8AAGXEAQADAOcA AADFAwAAAAAAACQDAAAAAEMAAAAZUHJvcG9zZWQgSW50ZXJuZXQtRHJhZnQJUwAAAAtyb2dlciBk ZWJyeQtyb2dlciBkZWJyeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --Boundary=_0.0_=5030100002202840-- From ipp-archive Thu Nov 21 10:52:08 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA24914 for ipp-outgoing; Thu, 21 Nov 1996 10:49:39 -0500 (EST) Message-Id: <199611211549.KAA24909@lists.underscore.com> Date: Thu, 21 Nov 96 08:14:37 MST From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" To: ipp@pwg.org Subject: IPP Prototyping Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi, I am working with Roger at IBM with the responsibility of modeling and prototyping elements of the IPP. The initial efforts will be to help us refine our understanding of the protocol and provide useful feedback to the group. The prototyping will hopefully evolve into a test-bed that will allow us to experiment with different implementations and guide future printer product development. As a precursor to prototyping, I have started on an object model to describe a printing system (clients and servers). Much of it is an elaboration of the IPP document to a level that will permit prototyping. I have chosen Rumbaugh's OMT methodology, or at least notation, in which to develop and describe the model. I expect that most of my prototying will be in Java. I am interested in ideas that other members of the group have regarding prototyping and will volunteer to coordinate efforts for discussions among those responsible for prototyping or providing input into prototyping at the various companies. Please let me know if there is interest in this. I can be contacted through this forum, by email at smg1@vnet.ibm.com or at (303)-924-5661. Thanks. From ipp-archive Thu Nov 21 11:57:11 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25236 for ipp-outgoing; Thu, 21 Nov 1996 11:53:32 -0500 (EST) Message-Id: <199611211653.LAA25228@lists.underscore.com> To: "internet-draft%ietf.org" Cc: "ipp%pwg.org" From: Don Wright Date: 21 Nov 96 9:49:05 EST Subject: New Internet Draft Request Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO A working group is in the process of being chartered in the applications area to develop a protocol for Internet printing. We have a BOF scheduled for Dec 12th in San Jose. I have developed a requirements document for that work that needs to be published. The title of that document is: "Requirements for WEB Browse-based Internet Printing" The abstract is: --------------- This document describes the requirements for WEB browser-based 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. URL) 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. -------------- I would like a document name assigned so that we can make this draft available ASAP. The name I suggest is: draft-wright-ipp-reqmts-01.txt Your prompt response is requested. Thanks! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 21 12:07:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25762 for ipp-outgoing; Thu, 21 Nov 1996 12:05:29 -0500 (EST) Date: Thu, 21 Nov 96 10:04:41 MST From: jeff@boulder.qms.com (Jeff Copeland) Message-Id: <9611211704.AA27256@boulder.qms.com> To: Angelo_Caruso@wb.xerox.com, ipp@pwg.org Subject: RE: Directory Entry Schema Cc: Scott_Isaacson@novell.com Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > > Scott, > > In my opinion subjective attributes are not very useful. Print quality, > for example, is so subjective that 'high', 'medium', and 'low' just > don't cut it. Also, a user's perception of 'high' or 'low' print > quality evolves with the state of the art. Why not specify objective > attributes like resolution, process (e.g. ink-jet, laser, etc.), color > capability (e.g. monchrome, full process color, etc.)? Cost is also > highly subjective (one man gathers what another man spills). Marketers > are constantly manipulating cost-per-page estimates in order to > position a product more competitively (some include only toner, some > include other supplies as well). Costs also evolve very rapidly over > time. Who would make these subjective judgements? > > My two cents per page :) > Angelo Caruso > Xerox Corp. First, you can make cost objective by using the actual cost, if you're in a commercial environment: e.g., at Kinko's, it's what the customer gets charged. Otherwise, ignore it, or use an arbitrary measure --- the 300 dpi monochrome is 25 units per page, but the 600dpi color is 150 units per page. As I suggested yesterday during the conference call, there is a way of overlaying the subjective and objective criteria. We provide objective measures of resolution, colors, process, speed and cost. Then, we can overlay those with a user or administrator programmable high, medium, low measure. That is, we specify in the browser setup what the allowable range is for each level. The H/M/L measure can drift over time, as mean printer speed and quality increases, by resetting those ranges in the browser setup. We can also provide a single H/M/L "quality" (or pick a better adjective) measure, where high is a combination of >600dpi + >2colors + laser or dye sublimation, for example. This means the printer tells us the objective measures, but the administrator's agent tells us the subjective ones. From ipp-archive Thu Nov 21 12:07:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25611 for ipp-outgoing; Thu, 21 Nov 1996 12:02:14 -0500 (EST) From: kcarter@VNET.IBM.COM Message-Id: <199611211702.MAA25603@lists.underscore.com> Date: Thu, 21 Nov 96 09:57:10 CST To: ipp@pwg.org cc: mccarter@mail.utexas.edu Subject: LDAP section of IPP spec Sender: ipp-owner@pwg.org Precedence: first-class Status: RO IPP Team, Here is the draft for how to register Printer objects using LDAP. I based this on my reading of RFCs 1777, 1823, 1959 and 1960. *** I will be at home so please send comments to the IPP mailing list and *** cc mccarter@mail.utexas.edu so I receive the comments at home. Thanks. 4.3 Printer Object Directory Entry and Location To allow directory users to locate an IPP printer, a corresponding Printer object must be defined as a directory entry. The directory entry includes the name of the entry and the attributes as defined in "4.2 Directory Entry Schema". An example of how to define a directory entry for a Printer object using LDAP is given to assist the reader's understanding of this specification. To create a Printer object directory entry using LDAP: 1. An administrator uses a program to create an entry for the Printer object on a directory server that supports LDAP. The administrator defines the Distinguished Name (dn) and the default subjective attributes for the Printer object directory entry. *** ISSUE: Should the administrator also define default objective attributes or wait for the Printer object to initialize these attributes? 2. The Printer object invokes the ldap_open API to open a connection to the directory server. Example: ld=ldap_open ("dir.host.name", LDAP_PORT) where ld is the connection handle for subsequent LDAP APIs. 3. The Printer object invokes an ldap "bind" API to authenticate with the directory server. Example: ldap_simple_bind_s (ld, dn, NULL) which does a simple authentication without a password. 4. The Printer object invokes the ldap_modify or ldap_modify_s API to define the objective attributes for the Printer object entry as identified by is Distinguished Name (dn). Example: ldap_modify_s (ld, dn, mods) where mods is a NULL-terminated array of objective attributes and values to add or modify in the directory entry. 5. The Printer object invokes the ldap_unbind API to close the connection to the directory server. Example: ldap_unbind (ld) When one or more objective attributes are modified for a Printer object, the Printer object repeats steps 2-5 to update the modified objective attributes in its directory entry. To locate a Printer object entry using LDAP, a program can use the ldap_search or ldap_search_s API or a user can specify an LDAP URL. For example, to locate all Printer objects that support duplex, a user can specify URL: ldap:///dir.host.name???(sides-supported=2-sided-long-binding-edge) ISSUE: Should one filter the search for an object class of Printer? Do we need to define this object class? If so, how? Please refer to the following RFCs for more information on LDAP: RFC 1777 - Lightweight Directory Access Protocol RFC 1823 - The LDAP Application Program Interface RFC 1959 - An LDAP URL Format RFC 1960 - A String Representation of LDAP Search Filters Keith From ipp-archive Thu Nov 21 12:52:14 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA26028 for ipp-outgoing; Thu, 21 Nov 1996 12:50:11 -0500 (EST) Message-Id: Date: Thu, 21 Nov 96 12:50 EST From: jkm@underscore.com (JK Martin) To: pwg@pwg.org, ipp@pwg.org Subject: Relocation of the Word document tool for the "Concept Virus" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Please note that the tool described below has been relocated on the PWG ftp server to: ftp://ftp.pwg.org/pub/tools/scanprot.doc Please note the change in filename (as there was a typo in the msg below?). Also note that the /pub/pwg/tools directory is new on the server; all similar PWG-related "tools" should be placed there. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- >From pwg.org!ipp-owner Wed Nov 20 07:48:08 1996 To: "ipp%pwg.org" From: Don Wright Date: 20 Nov 96 7:45:15 EST Subject: ipp92.doc - Concept Virus Mime-Version: 1.0 I have cleaned ipp92.doc and removed the concept virus. I have replaced the copy on the ftp server with a clean one. Additionally, I have posted a copy of scanprot.doc which you can use on your system to clean up the effects of the virus and scan your .doc files to see if any others are infected. Scanprot.dot can be found in: ftp://ftp.pwg.org/pub/pwg/ipp/tools/scanprot.dot ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* ----- End Included Message ----- From ipp-archive Thu Nov 21 13:12:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA26520 for ipp-outgoing; Thu, 21 Nov 1996 13:12:01 -0500 (EST) Message-Id: Date: Thu, 21 Nov 96 13:12 EST From: jkm@underscore.com (JK Martin) To: pwg@pwg.org, ipp@pwg.org Subject: Re: Relocation of the Word document tool for the "Concept Virus" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Sorry, but apparently I was looking at the wrong typo in the original message when the virus tool was relocated. Please note that this tool may now be found in: ftp://ftp.pwg.org/pub/tools/scanprot.dot Note that the file extension is now ".dot" instead of ".doc". ...jay ----- Begin Included Message ----- >From lexmark.com!don Thu Nov 21 13:07:48 1996 To: JK Martin From: Don Wright Date: 21 Nov 96 13:06:22 EST Subject: Re: Relocation of the Word document tool for the "Concept Virus" Mime-Version: 1.0 The file should be scanprot.dot not .doc. dot's are template and I think this needs to be one. Don To: pwg%pwg.org @ interlock.lexmark.com @ SMTP, ipp%pwg.org @ interlock.lexmark.com @ SMTP cc: (bcc: Don Wright) From: jkm%underscore.com @ interlock.lexmark.com (JK Martin) @ SMTP Date: 11/21/96 12:57:46 PM Subject: Relocation of the Word document tool for the "Concept Virus" Please note that the tool described below has been relocated on the PWG ftp server to: ftp://ftp.pwg.org/pub/tools/scanprot.doc Please note the change in filename (as there was a typo in the msg below?). Also note that the /pub/pwg/tools directory is new on the server; all similar PWG-related "tools" should be placed there. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- ----- Begin Included Message ----- >From pwg.org!ipp-owner Wed Nov 20 07:48:08 1996 To: "ipp%pwg.org" From: Don Wright Date: 20 Nov 96 7:45:15 EST Subject: ipp92.doc - Concept Virus Mime-Version: 1.0 I have cleaned ipp92.doc and removed the concept virus. I have replaced the copy on the ftp server with a clean one. Additionally, I have posted a copy of scanprot.doc which you can use on your system to clean up the effects of the virus and scan your .doc files to see if any others are infected. Scanprot.dot can be found in: ftp://ftp.pwg.org/pub/pwg/ipp/tools/scanprot.dot ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* ----- End Included Message ----- ----- End Included Message ----- From ipp-archive Thu Nov 21 14:17:10 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA27151 for ipp-outgoing; Thu, 21 Nov 1996 14:13:50 -0500 (EST) Message-Id: <199611211914.AA04265@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 21 Nov 96 14:13:50 EST Subject: Requirements Internet Draft Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have placed a copy of the requirements Internet Draft in /pub/ipp/drafts in ONLY .TXT format as that is what will be released to the IETF. The file is called: draft-wright-ipp-reqmts-00.txt After I get back the real name, etc from the IETF, I will post the -01 version to match what is submitted to the IETF. I will leave the old drafts (draft-wright-ipp-req-01.*) in the directory until I place the official IETF draft in the directory. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 21 15:34:48 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA27422 for ipp-outgoing; Thu, 21 Nov 1996 15:29:04 -0500 (EST) Message-Id: <199611212029.AA07198@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 21 Nov 96 15:28:37 EST Subject: IPP Conference Call - December 4th Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO The next IPP conference call will be Wednesday, December 4 at 4PM EST (3 CST, 2 MST, 1 PST). The dial in number will be 1-423-673-6712, access code is 190148. I have reserved 25 lines and the call can last up to 2.5 hours. (Same phone number and access code as last time.) Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 21 17:37:12 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA27993 for ipp-outgoing; Thu, 21 Nov 1996 17:36:24 -0500 (EST) Message-Id: <199611212237.AA11070@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 21 Nov 96 17:34:57 EST Subject: Requirements Draft Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have received the name for the requirements document, and have forwarded the new version to the IETF for publication. It is also posted on the ftp server as: /pub/pwg/ipp/draft/draft-wright-ipp-req-00.txt All the changes requested (which were very simple) have been included and it has been formatted to fit the IETF's requirements so I don't expect much editing will be done on the IETF's end before publishing. I have removed the old versions because the naming chosen was very confusing. If for some reason, you need a copy of the old drafts, I have them. I know this didn't give you guys much time for comment but given the simplicity of the changes and the schedule we and the IETF are on, this needed to get done NOW! Thanks! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 21 17:42:12 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA28159 for ipp-outgoing; Thu, 21 Nov 1996 17:39:40 -0500 (EST) Message-Id: <199611212240.AA11121@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 21 Nov 96 17:37:44 EST Subject: Minutes Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have posted the minutes for yesterday's conference call on the ftp server as /pub/pwg/ipp/minutes/961120-ipp-conference-call.doc /pub/pwg/ipp/minutes/961120-ipp-conference-call.ps /pub/pwg/ipp/minutes/961120-ipp-conference-call.pdf Additionally, I have renamed the files from the previous conference call to fit this naming convention. They are now: /pub/pwg/ipp/minutes/961113-ipp-conference-call.* Thanks! Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Thu Nov 21 18:52:12 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA28415 for ipp-outgoing; Thu, 21 Nov 1996 18:50:29 -0500 (EST) Date: Thu, 21 Nov 1996 15:50:36 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611212350.PAA27291@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: 0.92 review comments X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > > Section 6.4.32 > Since maximum-end-user-priority is a Printer object attribute and not a > Job Templates attribute, it is hard to acheive the desire effect. Suppose > you want some users to have a MAX priority of low and some user to > have a MAX of hight. This would require defining TWO Printer object for > the same Printer object not just TWO Job Templates for the same Printer > Object. However, this doesn't work as a Job Template attribute either - > the user just overrides the priority in the Job submission attributes > The above comment brings up a concept which cannot be connected to job templates. A job template specifies default values, but cannot restrict values. A printer specifies allowed values, and can therefore restrict values. In the case above where a printer wants to present two levels of priority to different users, a mechanism other than job template is required. Whatever it is, it is beyond our current scope. Bob Herriot From ipp-archive Thu Nov 21 19:32:14 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28637 for ipp-outgoing; Thu, 21 Nov 1996 19:29:23 -0500 (EST) Message-Id: <9611211801.AA23779@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 09:58:16 PST To: ipp@pwg.org From: Tom Hastings Subject: I've created a http-related-rfcs directory under ipp/ Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Discussing with Carl-Uno, this new http-related-rfcs directory will be temporary, until the ipp web page is available. Then we can point to the rfcs from the web page, instead of copying them to the pwg server. But until then, here is what we have: -rw-r--r-- 1 pwg pwg 16402 Nov 21 17:53 pvcsc-01.txt -rw-r--r-- 1 pwg pwg 187424 Nov 21 17:54 rfc1521.txt -rw-r--r-- 1 pwg pwg 32913 Nov 21 17:55 rfc1563.txt -rw-r--r-- 1 pwg pwg 26726 Nov 21 17:56 rfc1867.txt -rw-r--r-- 1 pwg pwg 137582 Nov 21 17:56 rfc1945.txt -rw-r--r-- 1 pwg pwg 106299 Nov 21 17:56 rfc822.txt We'll create another temporary ldap-related-rfcs directory shortly. Tom From ipp-archive Thu Nov 21 19:32:15 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA28645 for ipp-outgoing; Thu, 21 Nov 1996 19:29:28 -0500 (EST) Message-Id: <9611212346.AA23968@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 15:43:10 PST To: PPacumio@novell.com From: Tom Hastings Subject: Suggestion for pwg and ipp web pages Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Patrick, Thanks for volunteering to do PWG and IPP web pages. It would be good to have a list of related rfcs for the printer MIB and for the ipp standard. We all have a lot of homework to do in studying these other RFCs. An interesting question is how can additions RFCs be contributed? Could there be a mail checkbox in which any PWG member could contribute an additional RFC with a brief description? Probably, that is too fancy for the first go around. So we should probably just mail you with the RFC reference and one line descriptions. How should the related RFCs be grouped? So far, I think that there are the following categories of RFCs that relate to IPP: HTTP LDAP security The PWG page should be an umbrella page, listing the four activities of the PWG which each have their own home pages: Printer MIB (PMP) Internet Printing Protocol (IPP) Job Monitoring MIB (JMP) SENSE Lower priority would be to also have a Job Monitoring MIB (JMP) web page and a SENSE web page. I've started such a sub-directory on the PWG server, called http-related-rfcs, but a web page with a sentence or two about each related rfc and a pointer to the source, rather than copying, would be great. Jay, Or should we copy them to your server, to improve response but take up space? Patrick, Thanks for doing this, Tom Hastings From ipp-archive Thu Nov 21 20:02:13 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA29280 for ipp-outgoing; Thu, 21 Nov 1996 19:57:27 -0500 (EST) Message-Id: <9611220057.AA24038@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 16:55:03 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: 0.92 review comments [by Roger and Scott] Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Here are my comments on Roger's and Scott's comments. Lines with no preceding > are my comments. Tom >Return-Path: >From: rdebry@us1.ibm.com >X400-Originator: rdebry@us1.ibm.com >X400-Recipients: non-disclosure:; >X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002185444000002] >X400-Content-Type: P2-1988 (22) >To: , , > >Subject: 0.92 review comments >Date: Wed, 20 Nov 1996 06:19:34 PST > >Classification: >Prologue: >Epilogue: > >My comments noted by <> >---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/20/96 06:08 >AM --------------------------- > > ipp-owner @ pwg.org > 11/19/96 04:43 PM > > >To: ipp @ pwg.org@internet >cc: >Subject: 0.92 review comments > >Here are some comments, questions I have about some of the material in >IPP Version 0.92: > >Section 3.4 >This indicates one or more Job Templates per Printer. Should this be 0 or >more? > ><> I'd say 0 or more -- I thought we had agreed that output device ><> defaults would be used if there were no Job Template. I agree. 0 or more Job Templates per printer. Though a printer that doesn't have a Job Template may have a different URL scheme than one that does, if the URL naming scheme appends the local job template name to the printer name. Thus, a user who leaves off the template suffix (by accident), may be surprisde at what he gets, if the output device defaults are very user-friendly. > >Section 3.5 and Section 6.2.2.1 >3.5 states that a Job object is "identified" by an attribute called >job-identifier. 6.2.2.1 indicates that the syntax for job-identifier is >"url". Is the job-identifier really "url" or is the job-identifier just some >sting that can be used to build a full URL based off of the Printer URL? For >example a URL for a certain job might be "http://1.2.3.4/p1/j1". In this case >is the job-identifier "http://1.2.3.4/p1/j1" or just "j1"? > >If job-identifier is "http://1.2.3.4/p1/j1" then why have job-identifier as an >attribute of the job object? It would be fairly useless to do the following: > ><> I expect that the Printer object could return either form, but I ><> prefer returning a full URL. Although not a big deal this would make ><> the cient logic a little simpler which helps achieve our goal of very ><> thin clients. I agree that the job-identifier in IPP should be the full URL. Whether the job-identifier is an attribute of the job object (and the printer-name URL is an attribute of the printer object), is an interesting question. The only advantage for having the identifier of the object as an attribute is for use in filter expressions, since we can define the protocol to always return the identifier of each object requested. In a filter expression, you can write expressions that include or exclude printers if the printer-name is an attribute of the printer object, since filter expressions deal with attributes of candidate objects. > >----> >POST http://1.2.3.4/p1/j1 http/1.0 >Entity header > job-identifier: > ><> Scott, I don't know what you intended this flow to do, so it is hard to ><> comment precisely. However, it is true that sending the message to the ><> URL specified as the Job-identifier and then putting the job identifier ><> in the body of the message as well doesn't make much sense. If I were ><> asking for status of a previously submitted job, for example, ><> I would see this flow as: > ><> -----> ><> POST http://1.2.3.4.p1/j1 ><> Entity Header ><> current-job-state : null > ><> The Printer would respond by filling in the actual value of the ><> current job state attribute. Now, it may need to add the job-identifier ><> attribute in the response so that the client knows which job request >this ><> response belongs to. ><------ >http/1.0 200 "accepted" >Entity Header > job-identifier: http://1.2.3.4/p1/j1 > > >The same is true for section 6.4.1 printer-name. Is this a name or a URL? > ><> I thought that printer-name was used for the purpose of indicating ><> to the end user which output device his or her print job was actually ><> printed on in cases where a Printer Object represents multiple ><> ouput devices. If this is correct, then I'd suggest that printer-name ><> is NOT a URL, but an installation defined name recognizable by humans ><> to describe the printer. To be consistent with our terminology, perhaps ><> we should call this . I agree with Roger. The syntax is name, not url. Or even the name should be: local-output-device-name, since it may want to be the name that the output device is know by local to the printer. Then the URL name can be something that isn't obviously related to the local-output-device-name. This will help initial usage of this standard with existing printers as system administrators set up URLs for existing printers. They may not want to be saddled with inventing a URL that is tied to the local name that the local users are familar with. > >Section 4.2.2 and 4.2.3 >If there are more than one different URLs for a single Printer and the >reason for more than one is to expose different Job Templates, then the >Description attribute could be used to help explain the differences in the >defaults in each Job Template. There can also be more than one >directory entry for the same URL. Tthe reason for this is to expose the >same Printer in two different contexts in the directory. Tthe location >attribute for each directory entry could be customized to the context of >the directory entry. For example, in one context the Location could be >informal "Next to Sharon's office" (the directory context itself adds >meaning to the phrase next to Sharon's office) and in another context the >Location could be more formal, such as "3rd floor, Room 5". Sound good. > >Section 5.2.1 >This states "job and document attributes" Should this just be Job >attributes? > ><> I think that it is okay as it is. Although document attributes ><> have been treated as one type of job attribute, we do introduce ><> the ability to have multiple documents per job and structuring ><> the flows this way makes it easier to introduce document objects ><> in the future if we decide it is necessary. I agree with Roger. We may never add per-document attributes, but we may, so lets not have to change the standard if we decide to. > >Section 5.2.2 >Job Id should be a URL coming back to the submitter. I agree. > >Section 5 >Many of this operations suggest passing in a list of attributes for which >values are being requested? What if the list is empty? Does this mean >all attribute values are to be returned, or none? > ><> That is what I had intended ... see lines 736-739. I agree. > >Section 5.5 >Should there be an option to request Jobs in: >1) Scheduled order >2) Any order > ><> I would assume that we would want to return in scheduled order. I agree. Seems simpler. > >Since we have no operators -- sould Get Jobs return: >All Job Ids? >Just Job Ids for the requesting end user? >Position in the schedule order (my jobs are j1, j2, j3, but their relative >positions are #3, #5, #99) >Job Ids and a small set of attributes: size, time, position?? > ><> This is an interesting question. I know that I'd like to see ><> all of the jobs in the queue so that I can better judge what ><> is going on at the printer, e.g. is my job about to print. ><> However, are there security/privacy issues here??? Perhaps ><> it is okay to let users see the entire queue as long ><> as we show just a limited amount of information, maybe just ><> job size, time submitted, and position in queue. > >I like Roger's suggestion of a count of the total number of jobs pending >and processing. So do I like adding a printer attribute which is a count of the number of jobs waiting to be printed or being printed. Then an administrator can set up a policy to hide all jobs that don't belong to you and you can still find out how busy the printer is. Also lets add the other printer attribute from the Job Monitoring MIB that we agree to in New Orleans: job-scheduling-algorithm with values: first-in-first-out and shortest-job-first > >Section 6.2.4.1 >Since we have a single operation to "submit" a job, will we ever have the >state "pre-processing"? Do we want to not have the "printing" state? > ><> I suspect that this is a result of the way that DPA operates. I ><> woudl agree taht it doesn't apply when there is a single submit ><> operation. I agree. Lets delete the "per-processing" state. I think we should keep the held and retained states, since we will need them in version 2.0. Adding states is troublesome to clients. > >Section 6.2.4.6 >Will we ever have the "documents-needed" reason? > ><> Wouldn't this be the case when I give a document URL in the print ><> request and the Printer has requested the document but it has not ><> yet arrived? Yes. > >job-sheets >Since we have job-sheets as only "none" or "defuault", isn't this just a >Boolean "TRUE = print the default banner" "FALSE = don't print the >default banner" > ><> Makes sense to me. I disagree. By keeping it as a type3Enum, the standard and the administrator are free to add other values. > >Section 6.4.32 >Since maximum-end-user-priority is a Printer object attribute and not a >Job Templates attribute, it is hard to acheive the desire effect. Suppose >you want some users to have a MAX priority of low and some user to >have a MAX of hight. This would require defining TWO Printer object for >the same Printer object not just TWO Job Templates for the same Printer >Object. However, this doesn't work as a Job Template attribute either - >the user just overrides the priority in the Job submission attributes > ><> We haven't talked much abut how Job Templates could be used to ><> set up administrative stuff. Another good example would be ACLs ><> on a Job Template basis ... e.g. Anyone in dept A can print on ><> this printer, but only the manager can print transparencies. ><> Therefore only the manager shows up on the ACL of the Job ><> template for the "foils" printer. This whole arae probably ><> deserves some discussion. We've had lots of experience with this problem in ISO DPA. Job templates are just like initial value jobs (except IPP has improved them by having a URL that implies both a Job Template and a Printer). However, Job Templates are only defaults, they are not policy. Anything that can be said in a template can be said by the submitter. However, we could (and I thought we were) handle the above case by fan-in, where two Printers don't queue/spool, but just are a pass through to another Printer object that does queue/spool. Then the access control and the xxx-supported attributes on each of the two Printers can be different. As far as the user is concerned, the two Printers look like any other Printer. In other words, a Printer object that doesn't queue/spool and feed another Printer object is exactly what ISO DPA calls a logical printer. So we can solve the problem of maximum-end-user-priority being different for different users, by having the system administrator set up two Printers, one with a higher maximum-end-user-priority than the other and setting up two different acls on each. The SA also sets each Printer not to queue or spoool and to feed jobs to another Printer that does queue and spool (and that may or may not be in the directory, depending on whether the SA want to allow users to submit directly to it or not). Ok? > >All for now, >Scott > > > > From ipp-archive Thu Nov 21 21:04:49 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA29681 for ipp-outgoing; Thu, 21 Nov 1996 21:00:07 -0500 (EST) Message-Id: Date: Thu, 21 Nov 96 20:59 EST From: jkm@underscore.com (JK Martin) To: hastings@cp10.es.xerox.com Subject: Re: Suggestion for pwg and ipp web pages Cc: ipp@pwg.org, pwg@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom, > I've started such a sub-directory on the PWG server, called > http-related-rfcs, but a web page with a sentence or two about each related > rfc and a pointer to the source, rather than copying, would be great. > > Jay, > > Or should we copy them to your server, to improve response but take up space? Let's not copy any document or similar resource unless there is some absolutely compelling reason to do so. For web pages, just insert the URL reference. For the current ftp situation, I am very much *against* copying those files onto the PWG server. Instead, a "readme.related-rfcs" file should be created (and maintained!) that allows folks to pull down the entire list, then go to the appropriate ftp server (or whatever) to fetch the desired documents. A word of warning here, Tom. We are not about to let the PWG file server get out of control as badly as when it was hosted by HP. The existing state of the file structuring of the old PWG documentation is an utter mess. Let's not allow the IPP (or any other project, for that matter) fall into this trap. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Thu Nov 21 21:12:13 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00157 for ipp-outgoing; Thu, 21 Nov 1996 21:08:07 -0500 (EST) Message-Id: Date: Thu, 21 Nov 96 21:08 EST From: jkm@underscore.com (JK Martin) To: hastings@cp10.es.xerox.com Subject: Re: 0.92 review comments [by Roger and Scott] Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom, You wrote: > Subject: Re: 0.92 review comments [by Roger and Scott] > > Here are my comments on Roger's and Scott's comments. > Lines with no preceding > are my comments. Funny, but I can't seem to find the original messages by Roger and Scott in the IPP mailing list archives. There's a lot of discussion going on in those messages that would be very good for us to see, particularly since it deals with the expected "HTTP flows" of messages, etc. Recall that this situation was discussed during the last IPP telecon. Were those messages posted to the IPP list? ...jay From ipp-archive Thu Nov 21 21:57:13 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA00667 for ipp-outgoing; Thu, 21 Nov 1996 21:52:35 -0500 (EST) Message-Id: <3.0.32.19961121185353.00768364@elroy> X-Sender: bsetterb@elroy X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 21 Nov 1996 18:53:54 -0800 To: Carl-Uno Manros From: Bob Setterbo Subject: Re: PING Confirmations for IETF BOF Cc: ipp@pwg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >> >>Hi, >> >>This is the current list of BOF participants: >> >>Roger deBry IBM >>Tom Hastings Xerox >>Robert Herriot Sun >>Scott Isaacson Novell >>Raymond Lutz Cognisys >>Carl-Uno Manros Xerox >>Jay Martin Underscore >>Bill Wagner DPI, Osicom >>Rob Whittle Novell >>Don Wright Lexmark >> >>It is still shorter than I had hoped for. Did I miss anybody? Any more >>planning to participate who have not yet answered the PING? >> >>Carl-Uno >> >> >>Carl-Uno Manros >>Xerox Corporation >>701 S. Aviation Blvd. >>M/S: ESAE-231 >>El Segundo, CA 90245, USA >>E-mail: manros@cp10.es.xerox.com >> >> >> =================================================== Bob Setterbo Voice 415-962-3521 Location: Adobe Emeryville =================================================== From ipp-archive Thu Nov 21 22:02:14 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA00831 for ipp-outgoing; Thu, 21 Nov 1996 22:00:32 -0500 (EST) Message-Id: <9611220240.AA24099@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 18:37:57 PST To: Scott_Isaacson@novell.com (Scott Isaacson) From: Tom Hastings Subject: Some Comments on ipp92.doc - the issues we didn't get to address Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Most of these comments are on the ISSUES listed in the document that we didn't get time to address. 1. 6.1 Attribute syntaxes Need to add explanation of the notation in side the parens: "#" in front of a data syntax means zero or more values "1#" in front of a data syntax means one or more values 2. 6.1 Attribute syntaxes Get rid of the TBDs 3. 6.2.4.2 printer-assigned (name) ISSUE: Get rid of it. Not needed for our model. But maybe change it to local-output-device-name-used. As the text indicates, this will help a user find the output if the user has to do it himself/herself. 4. 6.2.6.1 notification-events ISSUE: Need to add a notification-address URL which allows the user or the client to specify mail:// or http:// We have an 6.3.2 operation-notification-address that the client software sets automatically. But if the end-user needs to be able to choose between mail and http, we may need to add a notification method or a notification- address that the user can supply. 5. 6.2.7.4 job-retention-period ISSUE: Ok to delete for version 1.0. It will come back when we do ResubmitJob operation but that is when we need it, not now. Same for 6.4.31 maximum-job-retention-period. But keep the retained state (even though not user affected in version 1.0), since its hard for client when the servers add states. 6. 6.2.8.2 number-up ISSUE: A simpler way to allow end-users to turn of embellishments, is to have a distinguised value that turns it off. ISO DPA has "0", but a more user friendly value would be "none". Then any other value, like "1", or "2", or "4" is free to have any embellishments on it. 7. 6.2.12.1 document-format ISSUE: Yes, make version optional. The problem is that if a driver says PostScript level 2, but doesn't use any level 2 features, then a level 1 printer is probably going to reject when it could have printed the document. This is a tough problem. 8. 6.3.2 operation-notification-address ISSUE: Keep, it cannot be inferred from the operation-user-name and operation-host-name in call cases. 9. Additional job attributes: add number of intervening jobs, so that you can see your position in the queue, even if the site policy is not to let you see any other jobs. 10. Additional printer attributes: a. add number of jobs waiting to be printed or being printed b. add scheduling algorithm with values: first-come-first-served and shortest-job-first 11. Explain that the term Printer and the Printer object need not be restricted to printing, but can be used to represent other kinds of output processing. Tom From ipp-archive Thu Nov 21 22:27:15 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA01041 for ipp-outgoing; Thu, 21 Nov 1996 22:26:32 -0500 (EST) Date: Thu, 21 Nov 1996 19:23:13 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611220323.TAA27677@woden.eng.sun.com> To: Scott_Isaacson@novell.com, hastings@cp10.es.xerox.com Subject: Re: Some Comments on ipp92.doc - the issues we didn't get to address Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > > Most of these comments are on the ISSUES listed in the document that > we didn't get time to address. > > 1. 6.1 Attribute syntaxes > > Need to add explanation of the notation in side the parens: > > "#" in front of a data syntax means zero or more values > "1#" in front of a data syntax means one or more values > * means zero or more items, # means 0 or more items in a list, each separated by a comma ",". The syntax is defined in rfc 822 and rfc 1945. We should just lift it all, word for word. > > 2. 6.1 Attribute syntaxes > > Get rid of the TBDs > > > 3. 6.2.4.2 printer-assigned (name) > > ISSUE: Get rid of it. Not needed for our model. > > But maybe change it to local-output-device-name-used. > As the text indicates, this will help a user find the output if > the user has to do it himself/herself. If xxx-used have a special meaning, I suggest not calling it local-output-device-name-used. > > > 4. 6.2.6.1 notification-events > > ISSUE: > Need to add a notification-address URL which allows the user or > the client to specify mail:// or http:// Is 'mail://' defined in some rfc? > > We have an 6.3.2 operation-notification-address that the client software sets > automatically. But if the end-user needs to be able to choose between > mail and http, we may need to add a notification method or a notification- > address that the user can supply. > > > 5. 6.2.7.4 job-retention-period > > ISSUE: > Ok to delete for version 1.0. It will come back when we do ResubmitJob operation > but that is when we need it, not now. Same for 6.4.31 > maximum-job-retention-period. But keep the retained state (even though > not user affected in version 1.0), since its hard for client when the > servers add states. > I am not sure I agree with the deletion of this feature. > > 6. 6.2.8.2 number-up > > ISSUE: > A simpler way to allow end-users to turn of embellishments, is to have > a distinguised value that turns it off. ISO DPA has "0", but a more > user friendly value would be "none". Then any other value, like "1", > or "2", or "4" is free to have any embellishments on it. I am trying to avoid arbitrary distinguished values that only IPP gurus know about. The question is whether a user would expect that number-up = 1 gives normal printing with essentially no number-up. > > > 7. 6.2.12.1 document-format > > ISSUE: > Yes, make version optional. The problem is that if a driver says > PostScript level 2, but doesn't use any level 2 features, then a > level 1 printer is probably going to reject when it could have printed > the document. This is a tough problem. > > > 8. 6.3.2 operation-notification-address > > ISSUE: > Keep, it cannot be inferred from the operation-user-name and operation-host-name > in call cases. > > > 9. Additional job attributes: > > add number of intervening jobs, so that you can see your position in > the queue, even if the site policy is not to let you see any other jobs. > This attribute is a 'maybe'. > > 10. Additional printer attributes: > > a. add number of jobs waiting to be printed or being printed > > b. add scheduling algorithm with values: first-come-first-served and > shortest-job-first We haven't addressed the issue of schedulers yet. > > > 11. Explain that the term Printer and the Printer object need not be > restricted to printing, but can be used to represent other kinds of > output processing. > > Tom > > > > > From ipp-archive Fri Nov 22 02:17:16 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA01447 for ipp-outgoing; Fri, 22 Nov 1996 02:12:30 -0500 (EST) Message-Id: <01BBD88F.E210DEE0@sedep58.cse.canon.co.jp> From: Hiroyuki Sato To: "hastings@cp10.es.xerox.com" , "'Robert Herriot'" , "Scott_Isaacson@novell.com" Cc: "ipp@pwg.org" Subject: RE^2: Some Comments on ipp92.doc - the issues we didn't get toaddress Date: Fri, 22 Nov 1996 16:11:55 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >> >> Most of these comments are on the ISSUES listed in the document that >> we didn't get time to address. >> >> 4. 6.2.6.1 notification-events >> >> ISSUE: >> Need to add a notification-address URL which allows the user or >> the client to specify mail:// or http:// > >Is 'mail://' defined in some rfc? If 'mail' means smtp, 'mailto' is a right one. More precise definition is 'mailto:End-User-Address@domain'. >> 5. 6.2.7.4 job-retention-period >> >> ISSUE: >> Ok to delete for version 1.0. It will come back when we do ResubmitJob operation >> but that is when we need it, not now. Same for 6.4.31 >> maximum-job-retention-period. But keep the retained state (even though >> not user affected in version 1.0), since its hard for client when the >> servers add states. >> > >I am not sure I agree with the deletion of this feature. > This maximum-job-retention-period/number is useful from a End user's point of view and our Salutation prototype experience. Hiroyuki Sato Canon From ipp-archive Fri Nov 22 06:00:46 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA01716 for ipp-outgoing; Fri, 22 Nov 1996 05:56:25 -0500 (EST) From: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 To: Carl-Uno Manros cc: moore@cs.utk.edu, ipp@pwg.org, xerox-ldpa@cp10.es.xerox.com Subject: Re: Proposed Charter for Internet Printing Protocol WG In-reply-to: Your message of "Wed, 20 Nov 1996 16:07:46 PST." <2.2.32.19961121000746.0094ac28@garfield> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Nov 1996 11:55:29 +0100 Message-ID: <10620.848660129@domen.uninett.no> Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Carl-Uno, I've passed the charter off to the Directorate for review, and also to agenda@ietf.org so that they got the agenda (VERY important). There's not much practical difference between a BOF and a WG, once you get there; you both have to provide minutes! There's one IESG telechat before San Jose; I doubt that it makes sense to change the status of the meeting at that time; it's so close to the meeting that it makes sense to get a sense of how the BOF goes before doing final decision on the charter. Harald A From ipp-archive Fri Nov 22 08:42:19 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA02024 for ipp-outgoing; Fri, 22 Nov 1996 08:39:36 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002218327000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002218327000002*@MHS> To: <"ipp@PWG.ORG"@??.ibm.com> Subject: IPP Security Date: Fri, 22 Nov 1996 08:39:08 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: I have drafted some thoughts on IPP security. I'd appreciate comments ...... ===================================================================== IPP Security White Paper As we add security to the IPP model we need to keep in mind the added complexity that security can bring to the system as well as the overhead in terms of network traffic and end-user response time. Running IPP on top of a Secure Sockets (SSL) session provides for message privacy, message integrity, and mutual authentication, but at some added cost. Therefore we might want to consider a model which allows several levels of security, at various cost points, to be configured by the system administrator: 1) No security: Anyone can submit jobs to the printer. No user ID or password is required. All data transmissions are in the clear. This is the cheapest solution and might well fit into environments not connected to the external Internet where anyone within the environment can freely access any printer. 2) Access Control - no password: The Printer object has an associated Access Control List (ACL), but no password is required to print. All data is sent in the clear. Users are not authenticated. 3) Access Control - password required: The Printer object has an associated ACL which has passwords for each authorized user. Users are not authenticated. 4) Authenticated access control: The Printer object has an associated ACL. Users identify themselves by sending their public key certificates to the Printer object. Data is still sent in the clear. This scheme would probably be the right level for controlled access within the Intranet. It is still fairly lightweight, but guarantees that only authenticated users can access a given printer or printers. 5) SSL access control: Any communication with the printer is done over an SSL session. Public key certificates are required for both users and Printers. This method would be required where a Printer is made visible outside of the firewall. An SSL session is established, both client and Printer are authenticated, and all data is encrypted before being sent. Message integrity is checked for each transmission. Let*,s investigate each of these situations and see how it might impact the IPP specification. No Security ----------- In this simple case, the IPP model is used as described. If is required for some reason, for example, to print on a header sheet, the Printer would have to ask for it or it would have to be supplied with the Print request. If the Printer can prompt for we need to define the mechanics of how this works. For this simple case, I*,d suggest that it always be sent in the Print request. Access Control - No Password ---------------------------- This case would be much like the previous one, except that is now a required attribute. The printer must either prompt the user for it, or it must be supplied in the Print request. is checked against valid names in the Printers Access Control List. In this simple case, I*,d suggest that always be sent in the Print request. Access Control - Password Required ---------------------------------- This case builds on the previous one. The Printer either prompts for both and (a new attribute), or they are included in the Print request. and are both checked against valid names and passwords in the Printer*,s Access Control List. Again, I*,d suggest that these flow with the original Print request else we have to define some mechanism to prompt for them. Authenticated Access Control ---------------------------- Authenticated access control requires the use of public key certificates. One way to achieve this would be for the original Print request to carry the job-originator*,s public key certificate along with a digitally signed message to verify the identity of the requester. The Printer needs to now authenticate the job- originator*,s certificate, but this exchange is outside the scope of this protocol. The printer now has enough information to validate that the request really came from the named job-origina tor. If the job-originator name is in the Printer*,s Access Control List then the Print request is honored. Another, simpler approach to this would assume that the Printer*,s ACL actually contained the public key for each authorized user. The flow could then be something like: Print request ----------------------------------------------> Since the printer already has john doe*,s public key, it can decrypt the message hash, compare it, and validate that it came from john doe. (anyone else sending it would have to have john doe*,s private key). This would not be an unreasonable approach in a corporate intranet. Getting user*,s public keys into the ACL is outside of the scope of this specification. SSL Controlled Access --------------------- When a print service provider accepts print requests from outside of the firewall, it is critical that mutual authentication and full message privacy and integrity be provided. If I send a print job to something advertised as a "Kinko*,s Print shop", I*,d like to be sure that that is really where the print job is going. Likewise, for billing purposes, the print provider must guarantee that the requester is who he says he is. This level of security seems to require full use of an SSL session. In this case the client initiates a secure session with the print provider. Secure browsers use a well know port for an SSL session, we would have to do the same for IPP. During the initiation of the SSL session, the client and print provider agree on a protocol version, exchange public key certificates, select encryption algorithms, and use public key encryption algorithms to generate shared secrets. Now the IPP protocol runs over a secure session. Clearly, this is a lot of overhead, but seems to be required in this particular environment. Recommendation -------------- Based on the above, I*,d like to recommend the addition of two attributes The client would always send and would send or based on the type of security established in the system when it was configured. SSL would only be used if the system were configured that way, typically in open internet configurations. From ipp-archive Fri Nov 22 10:37:21 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02674 for ipp-outgoing; Fri, 22 Nov 1996 10:35:08 -0500 (EST) Message-ID: <3295C85E.794BDF32@underscore.com> Date: Fri, 22 Nov 1996 10:35:58 -0500 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: deBry Section 5.1 updates on FTP server Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've placed Roger deBry's last two Section 5.1 updates in FTP://ftp.pwg.org/pub/pwg/ipp/new/ ipp92-flows.doc ipp92-flows.ps ipp92-http_syntax.doc ipp92-http_syntax.ps /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 Nov 22 10:42:21 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA02852 for ipp-outgoing; Fri, 22 Nov 1996 10:39:52 -0500 (EST) Message-ID: <3295C979.59E2B600@underscore.com> Date: Fri, 22 Nov 1996 10:40:41 -0500 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: ipp@pwg.org Subject: Re: deBry Section 5.1 updates on FTP server References: <3295C85E.794BDF32@underscore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Correction: > > I've placed Roger deBry's last two Section 5.1 updates in > > FTP://ftp.pwg.org/pub/pwg/ipp/drafts/ ipp92-flows.doc > ^^^^^^ ipp92-flows.ps > ipp92-http_syntax.doc > ipp92-http_syntax.ps /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 Nov 22 12:27:22 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA03110 for ipp-outgoing; Fri, 22 Nov 1996 12:23:14 -0500 (EST) Message-Id: <2.2.32.19961122172133.0093a43c@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 09:21:33 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: PING Confirmations for IETF BOF Sender: ipp-owner@pwg.org Precedence: first-class Status: RO >Return-Path: >X-Sender: bsetterb@elroy >Date: Fri, 22 Nov 1996 08:50:04 PST >To: Carl-Uno Manros >From: Bob Setterbo >Subject: Re: PING Confirmations for IETF BOF > >I guess it helps to put some text in the message... I do plan to >participate. Steve Zilles also indicated to me that he would be attending >the BOF meeting. > >At 08:15 AM 11/22/96 PST, you wrote: >>Bob, >> >>You forwarded the IETF IPP PING to the ipp list, but you did not indicate >>whether you intended to participate or not. >> >>Carl-Uno >> >=================================================== >Bob Setterbo > Voice 415-962-3521 > Location: Adobe Emeryville >=================================================== > Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Fri Nov 22 13:17:23 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA03459 for ipp-outgoing; Fri, 22 Nov 1996 13:13:26 -0500 (EST) Message-Id: <9611221814.AA24361@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 10:11:37 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: Some Comments on ipp92.doc - the issues we didn't get to address [replies to Bob Herriot and Hiroyuki Sato] Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Here is a combined reply to Bob Herriot and Hiroyuki Sato on my original comments. My comments don't have any > before them. Tom >Return-Path: >Date: Thu, 21 Nov 1996 19:23:13 PST >From: robert.herriot@eng.sun.com (Robert Herriot) >To: Scott_Isaacson@novell.com, hastings@cp10.es.xerox.com >Subject: Re: Some Comments on ipp92.doc - the issues we didn't get to > address >Cc: ipp@pwg.org >X-Sun-Charset: US-ASCII > > >> >> Most of these comments are on the ISSUES listed in the document that >> we didn't get time to address. >> >> 1. 6.1 Attribute syntaxes >> >> Need to add explanation of the notation in side the parens: >> >> "#" in front of a data syntax means zero or more values >> "1#" in front of a data syntax means one or more values >> > >* means zero or more items, # means 0 or more items in a list, each separated by a comma ",". >The syntax is defined in rfc 822 and rfc 1945. We should just lift it all, word >for word. So 1# means one or more items in a list, each separated by a comma? Here is the complete text from RFC 822 on #RULE: LISTS: 2.7. #RULE: LISTS A construct "#" is defined, similar to "*", as follows: #element indicating at least and at most elements, each separated by one or more commas (","). This makes the usual form of lists very easy; a rule such as '(element *("," element))' can be shown as "1#element". Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element),,(element)" is permitted, but counts as only two elements. Therefore, where at least one ele- ment is required, at least one non-null element must be present. Default values are 0 and infinity so that "#(element)" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two. NOTE that an empty value, e.g., ,, doesn't count. Therefore, it may be that such an empty value does not mean anything and that we should avoid allowing empty values to have any significance in either job or printer attributes. (I haven't had time to read all of rfc822). Therefore, we need distinguished values when we want nothing, such as "none". We already have a "none" value for (should be 6.2.5.1) job-sheets and 6.4.26 job-sheet-supported. In fact I think that 6.4.26 job-sheets-supported (#type3EnumState) should be changed to (1#type3Enum) in order to require at least one value. Otherwise we have to specify what the meaning is of no values supported (and our conformance requires that all attributes be supported). Also what are all the type2EnumState and type3EnumState syntaxes supposed to mean as opposed to type2Enum and type3Enum? > >> >> 2. 6.1 Attribute syntaxes >> >> Get rid of the TBDs >> >> >> 3. 6.2.4.2 printer-assigned (name) >> >> ISSUE: Get rid of it. Not needed for our model. >> >> But maybe change it to local-output-device-name-used. >> As the text indicates, this will help a user find the output if >> the user has to do it himself/herself. > >If xxx-used have a special meaning, I suggest not calling it local-output-device-name-used. I agree. I made a confusing suggestion. xxx-used atributes all mean "used by the program that created the PDL", not used by the Printer to print the job. How about local-output-device-assigned (analogous to ISO DPA printers-assigned)? >> >> >> 4. 6.2.6.1 notification-events >> >> ISSUE: >> Need to add a notification-address URL which allows the user or >> the client to specify mail:// or http:// > >Is 'mail://' defined in some rfc? Hiroyuki Sato wrote: >If 'mail' means smtp, 'mailto' is a right one. >More precise definition is 'mailto:End-User-Address@domain'. What rfc should we cite? > >> >> We have an 6.3.2 operation-notification-address that the client software sets >> automatically. But if the end-user needs to be able to choose between >> mail and http, we may need to add a notification method or a notification- >> address that the user can supply. >> >> >> 5. 6.2.7.4 job-retention-period >> >> ISSUE: >> Ok to delete for version 1.0. It will come back when we do ResubmitJob operation >> but that is when we need it, not now. Same for 6.4.31 >> maximum-job-retention-period. But keep the retained state (even though >> not user affected in version 1.0), since its hard for client when the >> servers add states. >> > >I am not sure I agree with the deletion of this feature. Neither did Hiroyuki Sato who wrote: >This maximum-job-retention-period/number is useful from a End user's >point of view and our Salutation prototype experience. So lets keep the job-retention-period job attribute and the maximum-job-retention-period printer attribute. > >> >> 6. 6.2.8.2 number-up >> >> ISSUE: >> A simpler way to allow end-users to turn of embellishments, is to have >> a distinguised value that turns it off. ISO DPA has "0", but a more >> user friendly value would be "none". Then any other value, like "1", >> or "2", or "4" is free to have any embellishments on it. > >I am trying to avoid arbitrary distinguished values that only IPP gurus know about. >The question is whether a user would expect that number-up = 1 gives normal printing >with essentially no number-up. No, I was suggesting that any value, except none, is free to include emblishments, such as borders, pages numbers, title lines, etc., including "1". So "1", "2", "4" all are free to include emblishments depending on the site policy. So "1" is just a way for a submitter to override some default that the system administrator set up, say "2", because the SA is concerned about saving trees. I think that it is an important design principle that when a system administrator can specify defaults that users have explicit ways to specify all values, especially the value ("1" in the case of number-up) that normally is used when neither the submitter supplies a value nor the SA defines a default). So the purpose of having a "none" value is for a submitter to be able to force no emblishments. Here is the current spec for number-up: 6.2.8.2 number-up (positiveInteger) This attribute specifies the number of source page images to impose upon a single side of an instance of a selected medium. In general, only certain numeric values are valid for this attribute, depending upon the Printer implementation to which the print request is directed. Typical supported values are 2 and 4. If this attribute is unspecified or has a value of 1, then the Printer does not apply any number-up transformation to the pages. This attribute primarily controls the translation, scaling and rotation of page images, but a site may choose to add embellishments, such as borders to each logical page. ISSUE: should there be a separate attribute to control embellishments, especially for the 1-up case? Bob, If you think allowing an implementor/SA to define emblishments as part of the semantics of "1", "2", and "4" is a bad idea, then maybe we should have another job attribute which controls emblishments, as suggested by the ISSUE. Maybe something like: embelishments (1#type3Enum) This attribute specifies the emblishments that are to be imposed upon a single side of an instance of a selected medium. Standard values are: "none", "borders", "impression numbers", "title". When used in combination with number-up, the "borders" emblishment means a border around each logical page that is imposed on a side of the medium. The "impression numbers" value means number each impression outside the area on which the logical pages are imposed. The "title" value means put the document name at the top of each impression outside the area on which the logical pages are imposed. Comments? > >> >> >> 7. 6.2.12.1 document-format >> >> ISSUE: >> Yes, make version optional. The problem is that if a driver says >> PostScript level 2, but doesn't use any level 2 features, then a >> level 1 printer is probably going to reject when it could have printed >> the document. This is a tough problem. >> >> >> 8. 6.3.2 operation-notification-address >> >> ISSUE: >> Keep, it cannot be inferred from the operation-user-name and operation-host-name >> in call cases. >> >> >> 9. Additional job attributes: >> >> add number of intervening jobs, so that you can see your position in >> the queue, even if the site policy is not to let you see any other jobs. >> >This attribute is a 'maybe'. Why is this attribute a maybe? We decided to have it for the Job Monitoring MIB in New Orleans. And other commentors suggested it too. If you list just your jobs, it would be helpful to also know the likely number of job ahead of you for each job. >> >> 10. Additional printer attributes: >> >> a. add number of jobs waiting to be printed or being printed >> >> b. add scheduling algorithm with values: first-come-first-served and >> shortest-job-first > >We haven't addressed the issue of schedulers yet. Some other commentor suggested that it would be helpful to be able to find out what type of scheduler the Printer object used. In my experience the two most common scheduling is FCFS and SJF. Of course the job-priority attribute is factored into these policies. Perhaps a better name for the printer attribute would be: job-scheduling-policy >> >> >> 11. Explain that the term Printer and the Printer object need not be >> restricted to printing, but can be used to represent other kinds of >> output processing. >> >> Tom From ipp-archive Fri Nov 22 13:42:22 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA03670 for ipp-outgoing; Fri, 22 Nov 1996 13:41:55 -0500 (EST) X-Nvlenv-01Date-Transferred: 22-Nov-1996 13:09:52 -0500; at X-WB-AREA-HUB.XEROX X-Nvlenv-01Date-Transferred: 22-Nov-1996 13:06:28 -0500; at X-WB-NGM-MIME.XEROX X-Nvlenv-01Date-Posted: 22-Nov-1996 13:10:01 -0500; at x-wb-0311-ms1.xerox Date: Fri, 22 Nov 1996 09:59:06 PST From: Angelo_Caruso@wb.xerox.com (Caruso,Angelo) To: ipp@pwg.org Subject: RE: Some Comments on ipp92.doc - the issues we didn't get to, ad Message-Id: <"<4EE9953281262D79>4EE9953281262D79@x-wb-0311-ms1.xerox"@-SMF-> Cc: hastings@cp10.es.xerox.com (Tom Hastings) Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom, Under 10. b) you list shortest-job-first as a scheduling algorithm. How does a printer determine the shortest job? A small file size does not neccessarily imply a short RIP time. Angelo From ipp-archive Fri Nov 22 14:17:23 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA03875 for ipp-outgoing; Fri, 22 Nov 1996 14:13:16 -0500 (EST) Message-Id: Date: Fri, 22 Nov 96 14:14 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: I-D ACTION:draft-holtman-http-negotiation-04.txt Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This paper might have some applicability for IPP at some point. ...jay ----- Begin Included Message ----- >From ietf.org!ietf-announce-request Fri Nov 22 13:14:47 1996 Mime-Version: 1.0 To: IETF-Announce: ; cc: http-wg@cuckoo.hpl.hp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-holtman-http-negotiation-04.txt Date: Fri, 22 Nov 1996 09:40:44 -0500 X-Orig-Sender: cclark@ietf.org --NextPart A Revised 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 : Transparent Content Negotiation in HTTP Author(s) : K. Holtman, A. Mutz Filename : draft-holtman-http-negotiation-04.txt Pages : 45 Date : 11/21/1996 HTTP allows one to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. Design goals for transparent content negotiation include: low overhead on the request message size, downwards compatibility, extensibility, enabling the rapid introduction of new areas of negotiation, scalability, low cost for minimal support, end user control, and good cacheability. 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-holtman-http-negotiation-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-holtman-http-negotiation-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-holtman-http-negotiation-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: <19961121133250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-holtman-http-negotiation-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-holtman-http-negotiation-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121133250.I-D@ietf.org> --OtherAccess-- --NextPart-- ----- End Included Message ----- From ipp-archive Fri Nov 22 14:22:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04175 for ipp-outgoing; Fri, 22 Nov 1996 14:19:19 -0500 (EST) Message-Id: Date: Fri, 22 Nov 96 14:20 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: Comments on shortest-job-first attribute Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Angelo wrote (in response to Tom Hasting's comments): > Under 10. b) you list shortest-job-first as a scheduling algorithm. How > does a printer determine the shortest job? A small file size does not > neccessarily imply a short RIP time. A very good point. Perhaps this attribute should be "smallest-job-first"? ...jay From ipp-archive Fri Nov 22 14:22:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04049 for ipp-outgoing; Fri, 22 Nov 1996 14:18:23 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 22 Nov 1996 11:00:25 -0700 From: "Scott A. Isaacson" To: hastings@cp10.es.xerox.com, jkm@underscore.com Cc: ipp@pwg.org Subject: Re: 0.92 review comments [by Roger and Scott] -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Yes, the only address I used for my original posting was ipp@pwg.org. I have cut and pasted the original below for anyone that might have missed it! Scott >>> JK Martin 11/21/96 07:08pm >>> Tom, You wrote: > Subject: Re: 0.92 review comments [by Roger and Scott] > > Here are my comments on Roger's and Scott's comments. > Lines with no preceding > are my comments. Funny, but I can't seem to find the original messages by Roger and Scott in the IPP mailing list archives. There's a lot of discussion going on in those messages that would be very good for us to see, particularly since it deals with the expected "HTTP flows" of messages, etc. Recall that this situation was discussed during the last IPP telecon. Were those messages posted to the IPP list? ...jay >>> JK Martin 11/21/96 07:08pm >>> >From Scott Isaacson 11/19/96 4:38 PM --------------------------------------------------------------------------------------- Here are some comments, questions I have about some of the material in IPP Version 0.92: Section 3.4 This indicates one or more Job Templates per Printer. Should this be 0 or more? Section 3.5 and Section 6.2.2.1 3.5 states that a Job object is "identified" by an attribute called job-identifier. 6.2.2.1 indicates that the syntax for job-identifier is "url". Is the job-identifier really "url" or is the job-identifier just some sting that can be used to build a full URL based off of the Printer URL? For example a URL for a certain job might be "http://1.2.3.4/p1/j1". In this case is the job-identifier "http://1.2.3.4/p1/j1" or just "j1"? If job-identifier is "http://1.2.3.4/p1/j1" then why have job-identifier as an attribute of the job object? It would be fairly useless to do the following: ----> POST http://1.2.3.4/p1/j1 http/1.0 Entity header job-identifier: <------ http/1.0 200 "accepted" Entity Header job-identifier: http://1.2.3.4/p1/j1 The same is true for section 6.4.1 printer-name. Is this a name or a URL? Section 4.2.2 and 4.2.3 If there are more than one different URLs for a single Printer and the reason for more than one is to expose different Job Templates, then the Description attribute could be used to help explain the differences in the defaults in each Job Template. There can also be more than one directory entry for the same URL. Tthe reason for this is to expose the same Printer in two different contexts in the directory. Tthe location attribute for each directory entry could be customized to the context of the directory entry. For example, in one context the Location could be informal "Next to Sharon's office" (the directory context itself adds meaning to the phrase next to Sharon's office) and in another context the Location could be more formal, such as "3rd floor, Room 5". Section 5.2.1 This states "job and document attributes" Should this just be Job attributes? Section 5.2.2 Job Id should be a URL coming back to the submitter. Section 5 Many of this operations suggest passing in a list of attributes for which values are being requested? What if the list is empty? Does this mean all attribute values are to be returned, or none? Section 5.5 Should there be an option to request Jobs in: 1) Scheduled order 2) Any order Since we have no operators -- sould Get Jobs return: All Job Ids? Just Job Ids for the requesting end user? Position in the schedule order (my jobs are j1, j2, j3, but their relative positions are #3, #5, #99) Job Ids and a small set of attributes: size, time, position?? I like Roger's suggestion of a count of the total number of jobs pending and processing. Section 6.2.4.1 Since we have a single operation to "submit" a job, will we ever have the state "pre-processing"? Do we want to not have the "printing" state? Section 6.2.4.6 Will we ever have the "documents-needed" reason? job-sheets Since we have job-sheets as only "none" or "defuault", isn't this just a Boolean "TRUE = print the default banner" "FALSE = don't print the default banner" Section 6.4.32 Since maximum-end-user-priority is a Printer object attribute and not a Job Templates attribute, it is hard to acheive the desire effect. Suppose you want some users to have a MAX priority of low and some user to have a MAX of hight. This would require defining TWO Printer object for the same Printer object not just TWO Job Templates for the same Printer Object. However, this doesn't work as a Job Template attribute either - the user just overrides the priority in the Job submission attributes All for now, Scott From ipp-archive Fri Nov 22 14:46:30 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA04432 for ipp-outgoing; Fri, 22 Nov 1996 14:39:23 -0500 (EST) From: kcarter@VNET.IBM.COM Message-Id: <199611221939.OAA04427@lists.underscore.com> Date: Fri, 22 Nov 96 13:13:45 CST To: ipp@pwg.org cc: mccarter@mail.utexas.edu Subject: Update on LDAP section of the IPP spec Sender: ipp-owner@pwg.org Precedence: first-class Status: RO IPP Team, I had 2 LDAP gurus review the attached section. Updates are indicated inline of the section via KC->. Everyone have a super holiday! Keith Received: from lists.underscore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Thu, 21 Nov 96 12:03:53 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id MAA25677; Thu, 21 Nov 1996 12:02:44 - Received: by pwg.org (bulk_mailer v1.5); Thu, 21 Nov 1996 12:02:18 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA25611 for ipp-outgoing; Thu, 21 Nov 1996 12:02:14 -050 From: kcarter@VNET.IBM.COM Message-Id: <199611211702.MAA25603@lists.underscore.com> Date: Thu, 21 Nov 96 09:57:10 CST To: ipp@pwg.org cc: mccarter@mail.utexas.edu Subject: LDAP section of IPP spec Sender: ipp-owner@pwg.org IPP Team, Here is the draft for how to register Printer objects using LDAP. I based this on my reading of RFCs 1777, 1823, 1959 and 1960. *** I will be at home so please send comments to the IPP mailing list and *** cc mccarter@mail.utexas.edu so I receive the comments at home. Thanks. 4.3 Printer Object Directory Entry and Location To allow directory users to locate an IPP printer, a corresponding Printer object must be defined as a directory entry. The directory entry includes the name of the entry and the attributes as defined in "4.2 Directory Entry Schema". An example of how to define a directory entry for a Printer object using LDAP is given to assist the reader's understanding of this specification. To create a Printer object directory entry using LDAP: 1. An administrator uses a program to create an entry for the Printer object on a directory server that supports LDAP. The administrator defines the Distinguished Name (dn) and the default subjective attributes for the Printer object directory entry. KC-> In "4.2 Directory Entry Schema", we must specify which attributes KC-> "must" be contained (i.e. mandatory) and which attributes "may" KC-> be contained (i.e. conditional) in a Printer object directory entry. KC-> "must" and "may" are LDAP terms. *** ISSUE: Should the administrator also define default objective attributes or wait for the Printer object to initialize these attributes? KC-> This is our decision. LDAP doesn't favor one approach over the other. 2. The Printer object invokes the ldap_open API to open a connection to the directory server. Example: ld=ldap_open ("dir.host.name", LDAP_PORT) where ld is the connection handle for subsequent LDAP APIs. 3. The Printer object invokes an ldap "bind" API to authenticate with the directory server. Example: ldap_simple_bind_s (ld, dn, NULL) which does a simple authentication without a password. 4. The Printer object invokes the ldap_modify or ldap_modify_s API to define the objective attributes for the Printer object entry as identified by is Distinguished Name (dn). Example: ldap_modify_s (ld, dn, mods) where mods is a NULL-terminated array of objective attributes and values to add or modify in the directory entry. 5. The Printer object invokes the ldap_unbind API to close the connection to the directory server. Example: ldap_unbind (ld) When one or more objective attributes are modified for a Printer object, the Printer object repeats steps 2-5 to update the modified objective attributes in its directory entry. To locate a Printer object entry using LDAP, a program can use the ldap_search or ldap_search_s API or a user can specify an LDAP URL. For example, to locate all Printer objects that support duplex, a user can specify URL: ldap:///dir.host.name???(sides-supported=2-sided-long-binding-edge) KC-> We need a printer object class (see answer to issue below). This KC-> changes the search example to the following: KC-> KC-> ldap:///dir.host.name???(&(objectClass=printer) KC-> (sides-supported=2-sided-long-binding-edge)) ISSUE: Should one filter the search for an object class of Printer? Do we need to define this object class? If so, how? KC-> We need a printer object class. The printer class should be KC-> subclass of the device class already defined in X.500. KC-> KC-> printer OBJECT-CLASS ::= { KC-> SUBCLASS OF {device} KC-> MUST CONTAIN {list of mandatory attributes} KC-> MAY CONTAIN {list of optional attributes} KC-> KC-> I'll find out the process for defining a printer class upon my return KC-> to the office on 12/2. Please refer to the following RFCs for more information on LDAP: RFC 1777 - Lightweight Directory Access Protocol RFC 1823 - The LDAP Application Program Interface RFC 1959 - An LDAP URL Format RFC 1960 - A String Representation of LDAP Search Filters Keith From ipp-archive Fri Nov 22 15:12:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA04925 for ipp-outgoing; Fri, 22 Nov 1996 15:08:03 -0500 (EST) Message-Id: <9611221953.AA24434@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_848721017==_" Date: Fri, 22 Nov 1996 11:50:17 PST To: ipp@pwg.org From: Tom Hastings Subject: Suggested text for the state syntax in IPP V0.92 X-Attachments: C:\HASTINGS\IETF-PWG\IPP\NEW\IPP-SYN.DOC; C:\HASTINGS\IETF-PWG\IPP\NEW\IPP-SYN.PDF; Sender: ipp-owner@pwg.org Precedence: first-class Status: RO --=====================_848721017==_ Content-Type: text/plain; charset="us-ascii" I've attached revisions to section 6.1 Attribute Syntax as .doc and .pdf I will post the files in \new\ipp92syn.doc and .pdf as soon as I can, but I was unable to change directories when logging into the PWG server so I could not post any documents! I was able to read documents using anonymous ftp though. I have a call into Jay and Jeff who are off-side for a few hours. A number of data syntaxes have the word State tacked on the end of them. The idea is that these data syntax values are used for the xxx-supported attributes of the printer object and indicate whether the supported value is ready or not, i.e., whether human intervention is needed in order for a job to use that value or not. I think that it is probably most useful to only indicate values that are not ready, rather than values that are, though that may be arguable. So the media-supported printer attribute might contain values like: media-supported=na-letter-white, na-letter-transparent, b:not-ready Meaning that na-letter-white and na-letter-transparent are loaded into the two trays of the output device and that b is supported but requires the operator to change the trays. We could even have a third value: on-order meaning that it will take even longer, but your job will print eventually. and a fourth value: special-order meaning that the provider will initiate a special order when the job is submitted and your job will print eventually. So I have attached my suggestions to fix the text in section 6.1 Here is the current contents in plain text without formatting: string arbitrary ASCII strings, no control characters, except .TBD stringPair string ":" string stringState string state name arbitrary ASCII strings, no control characters, and no characters.TBD URL Universal Resource LocatorTBD dateTime date and time in RFC 822 formatTBD deltaTime [hours ":"] minutes cardinal 0 .. n represented as ASCII digits type1Enum standard names, must revise the IPP standard to add a new name. No private names are allowed.TBD type2Enum standard names, but an implementor can add new TBDby proposing them to the PWG for registration (or an IANA-appointed registry advisor after the PWG is no longer certified) anytime. IANA keeps the registry. Implementors can add private (un-registered) with a suitable distinguishing prefix, such as -xxx- where xxx is the company name registered with IANA. type3Enum standard names, but an implementor can add new names by submitting a registration request directly to IANA, no PWG or IANA-appointed registry advisor review is required. Implementors can add private (un-registered) names with a suitable distinguishing prefix, such as -xxx- where xxx is the company name registered with IANA.TBD type2EnumState type2Enum state type3EnumState type3Enum state state TBD Boolean tokens: yes, y, true, or t and no, n, false, or f.TBD positiveInteger 1 .. n represented as ASCII digitsTBD positiveIntegerCross positiveInteger [ "x" positiveInteger ] positiveIntegerCrossState positiveIntegerCross state positiveIntegerRange positiveInteger ":" positiveInteger positiveIntegerUnits positiveInteger units positiveIntegerState positiveInteger state units "ppm" | "ipm" | "spm" | "cps" | "lpm" type3Locale type3Country ":" type3Language ":" type3CodeSet type3Country type3Enum type3Language type3Enum type3CodeSet type3Enum type2Format name [ "/" version ] version name type3LocaleState type3Locale state My suggestion is to define a new data syntax: State which begins with a capital letter, so that it cannot be used by itself, only in combination with other syntaxes in the above table. State [:not-ready] / [:on-order] / [:special-order] --=====================_848721017==_ Content-Type: application/msword; name="IPP-SYN.DOC"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IPP-SYN.DOC" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////GwAAAP7///8cAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAAB0AAAD+/////v// /x4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAP7///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8DAAAAAAkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAIaTM3cj07sB AwAAAIADAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf////8EAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAADBfAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBAQAAAAIA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAACGZgJ2I9O7AYZmAnYj07sBAAAAANQNNBRABNQNAQAA AP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8BAP7/ AwoAAP////8ACQIAAAAAAMAAAAAAAABGHAAAAE1pY3Jvc29mdCBXb3JkIDYuMCBEb2N1bWVudAAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYAAAAAADsAAwD+/wkABgAAAAAAAAAAAAAA AQAAAAEAAAAAAP7/AAADCgAAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA ANACAAAOAAAABwAAAJgAAAACAAAA3AAAAAQAAAAgAQAACAAAAEQBAAAMAAAAaAEAAAsAAACMAQAA DQAAALABAAAPAAAA1AEAABAAAAD4AQAACgAAABwCAAASAAAAQAIAAA4AAABkAgAACQAAAIgCAAAT AAAArAIAAP//////////////////////////////////////////HgAAACgAAABDOlxNU09GRklD RVxXSU5XT1JEXFRFTVBMQVRFXE5PUk1BTC5ET1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAIwAA AFN1Ymo6ICBJUFAgYXR0cmlidXRlcyBhbmQgc3ludGF4ZXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAB4AAAANAAAAVG9tIEhhc3RpbmdzAAAAAAAAAAAAAAAAAAAAAB4AAAANAAAAVG9tINylZQAz wAkEAAAAAGUAAAAAAAAAAAAAAAADAACQLQAAwXwAAAAAAAAAAAAAAAAAAAAAAACQKgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdgAAGgMAAAB2AAAaAwAAGnkAAAAAAAAaeQAAAAAA ABp5AAAAAAAAGnkAAAAAAAAaeQAAFAAAAJR5AAAAAAAAlHkAAAAAAACUeQAAAAAAAJR5AAAAAAAA lHkAAAAAAACUeQAAUgAAAOZ5AACOAAAAlHkAAAAAAADcewAAQwAAALR6AAAAAAAAtHoAAAAAAAC0 egAAAAAAALR6AAAAAAAAtHoAAAAAAAC0egAAAAAAALR6AAAAAAAAtHoAAAAAAADbegAAAgAAAN16 AAAAAAAA3XoAAAAAAADdegAAGQAAAPZ6AABkAAAAWnsAAGQAAAC+ewAAHgAAAB98AABUAAAAc3wA AE4AAADcewAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaeQAAAAAAALR6AAAAAAAAAAAXACQADQAXALR6 AAAAAAAAtHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtHoAAAAAAAC0egAAAAAAANx7AAAAAAAAtHoA AAAAAAAaeQAAAAAAABp5AAAAAAAAtHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdHoAAEAAAAC0egAA AAAAALR6AAAAAAAAtHoAAAAAAAC0egAAAAAAABp5AAAAAAAAtHoAAAAAAAAaeQAAAAAAALR6AAAA AAAA23oAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnkAACYAAABUeQAAQAAAABp5AAAAAAAAGnkAAAAA AAAaeQAAAAAAABp5AAAAAAAAtHoAAAAAAADbegAAAAAAALR6AAAnAAAAtHoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFN1Ymo6ICBJUFAgYXR0cmlidXRlcyBhbmQgc3ludGF4ZXMN RnJvbTogIFRvbSBIYXN0aW5ncw1GaWxlOiAgaXBwLXN5bi5kb2MNRGF0ZTogIDE1LU5vdi0xOTk2 DQ1FYWNoIGF0dHJpYnV0ZSBzaGFsbCBiZSBpbiBvbmUgb2YgdGhlIGZvbGxvd2luZyBkYXRhIHN5 bnRheGVzOg0NICAgc3RyaW5nICAgICAgIC0gYXJiaXRyYXJ5IEFTQ0lJIHN0cmluZ3MsIG5vIGNv bnRyb2wgY2hhcmFjdGVycywgZXhjZXB0IA0gICAgICAgICAgICAgICAgICA8U1BBQ0U+Lg0gICBz dHJpbmcgcGFpciAgLSBzdHJpbmdzIHNlcGFyYXRlZCBieSAiOiINICAgbmFtZSAgICAgICAgIC0g YXJiaXRyYXJ5IEFTQ0lJIHN0cmluZ3MsIG5vIGNvbnRyb2wgY2hhcmFjdGVycywgYW5kIG5vDSAg ICAgICAgICAgICAgICAgIDxTUEFDRT4gY2hhcmFjdGVycy4NICAgdHlwZSAxIGVudW0gIC0gc3Rh bmRhcmQgbmFtZXMsIG11c3QgcmV2aXNlIHRoZSBzdGFuZGFyZCB0byBhZGQgDSAgICAgICAgICAg ICAgICAgIGEgbmV3IG5hbWUuICBObyBwcml2YXRlIG5hbWVzIGFyZSBhbGxvd2VkLg0gICB0eXBl IDIgZW51bSAgLSBzdGFuZGFyZCBuYW1lcywgYnV0IGFuIGltcGxlbWVudG9yIGNhbiBhZGQgbmV3 IA0gICAgICAgICAgICAgICAgICBieSBwcm9wb3NpbmcgdGhlbSB0byB0aGUgUFdHIGZvciByZWdp c3RyYXRpb24gDSAgICAgICAgICAgICAgICAgIChvciBhbiBJQU5BLWFwcG9pbnRlZCByZWdpc3Ry eSBhZHZpc29yIGFmdGVyIHRoZSBQV0cgDSAgICAgICAgICAgICAgICAgIGlzIG5vIGxvbmdlciBj ZXJ0aWZpZWQpIGFueXRpbWUuICBJQU5BIGtlZXBzIHRoZSANICAgICAgICAgICAgICAgICAgcmVn aXN0cnkuDSAgICAgICAgICAgICAgICAgIEltcGxlbWVudG9ycyBjYW4gYWRkIHByaXZhdGUgKHVu LXJlZ2lzdGVyZWQpIA0gICAgICAgICAgICAgICAgICB3aXRoIGEgc3VpdGFibGUgZGlzdGluZ3Vp c2hpbmcgcHJlZml4LCBzdWNoIGFzIC14eHgtIA0gICAgICAgICAgICAgICAgICB3aGVyZSB4eHgg aXMgdGhlIGNvbXBhbnkgbmFtZSByZWlnaXN0ZXJlZCB3aXRoIElBTkEuDSAgIHR5cGUgMyBlbnVt ICAtIHN0YW5kYXJkIG5hbWVzLCBidXQgYW4gaW1wbGVtZW50b3IgY2FuIGFkZCBuZXcgDSAgICAg ICAgICAgICAgICAgIG5hbWVzIGJ5IHN1Ym1pdHRpbmcgYSByZWdpc3RyYXRpb24gcmVxdWVzdCBk aXJlY3RseSB0byANICAgICAgICAgICAgICAgICAgSUFOQSwgbm8gUFdHIG9yIElBTkEtYXBwb2lu dGVkIHJlZ2lzdHJ5IGFkdmlzb3IgcmV2aWV3IA0gICAgICAgICAgICAgICAgICBpcyByZXF1aXJl ZC4NICAgICAgICAgICAgICAgICAgSW1wbGVtZW50b3JzIGNhbiBhZGQgcHJpdmF0ZSAodW4tcmVn aXN0ZXJlZCkgbmFtZXMgDSAgICAgICAgICAgICAgICAgIHdpdGggYSBzdWl0YWJsZSBkaXN0aW5n dWlzaGluZyBwcmVmaXgsIHN1Y2ggYXMgLXh4eC0gDSAgICAgICAgICAgICAgICAgIHdoZXJlIHh4 eCBpcyB0aGUgY29tcGFueSBuYW1lIHJlaWdpc3RlcmVkIHdpdGggSUFOQS4NICAgdHlwZSAzIHBh aXIgIC0gdHdvIHR5cGUgMyBlbnVtIG5hbWVzIHNlcGFyYXRlZCBieSAiOiIuDSAgIGNhcmRpbmFs ICAgICAtIDAgLi4gbiByZXByZXNlbnRlZCBhcyBBU0NJSSBkaWdpdHMNICAgb3JkaW5hbCAgICAg IC0gMSAuLiBuIHJlcHJlc2VudGVkIGFzIEFTQ0lJIGRpZ2l0cw0gICBvcmRpbmFsIHBhaXIgLSB0 d28gb3JkaW5hbHMgc2VwYXJhdGVkIGJ5ICI6Ig0gICBib29sZWFuICAgICAgLSB0b2tlbnM6IHll cywgeSwgdHJ1ZSwgb3IgdCBhbmQgbm8sIG4sIGZhbHNlLCBvciBmLg0gICBkYXRlL3RpbWUgICAg LSBkYXRlL3RpbWUgaW4gPz8/IGZvcm1hdA0gICB1cmwgICAgICAgICAgLSBVbml2ZXJzYWwgUmVz b3VyY2UgTG9jYXRvcg0gICBvY3RldCBzdHJpbmcgLSBhcmJpdHJhcnkgYmluYXJ5IG9jdGV0cw0g ICBzdHJpbmcgdW5pdHMgLSBvcmRpbmFsIGZvbGxvd2VkIGJ5IHR5cGUgMiBlbnVtIHVuaXRzDQ1I ZXJlIGlzIHRoZSB1cGRhdGVkIGxpc3Qgb2YgYXR0cmlidXRlcyBmcm9tIG15IG5vdGVzIHdpdGgg ZGF0YSBzeW50YXhlczoNDQkJCUF0dHJpYnV0ZSBuYW1lB3N5bnRheAdzL20HB0pvYiBBdHRyaWJ1 dGVzBwcHBwkJSm9iIEluZm9ybWF0aW9uYWwgQXR0cmlidXRlcyAoc2V0IGJ5IGNsaWVudCkHBwcH CQkJam9iLW9yaWdpbmF0b3IgKGFuIGF1dGhlbnRpY2F0ZWQgdmFsdWUpB3N0cmluZwdzBwcJCQlq b2ItbmFtZQdzdHJpbmcHcwcHCQkJam9iLW9yaWdpbmF0aW5nLWhvc3QHBwcHCQlKb2IgSW5mb3Jt YXRpb25hbCBBdHRyaWJ1dGVzIChzZXQgYnkgUHJpbnRlcikHBwcHCQkJam9iLWlkZW50aWZpZXIH bmFtZQdzBwcJCQlqb2ItaWRlbnRpZmllci1vbi1vdXRwdXQtZGV2aWNlICh1c2VkIGJ5IG9wZXJh dG9yKQduYW1lB3MHBwkJUHJpbnRlciBTZWxlY3Rpb24gQXR0cmlidXRlcyAoc2V0IGJ5IGNsaWVu dCkHBwcHCQkJcHJpbnRlci1uYW1lLXJlcXVlc3RlZAduYW1lB3MHBwkJCW91dHB1dC1kZXZpY2Ut cmVxdWVzdGVkBwcHBwkJSm9iIFN0YXR1cyBBdHRyaWJ1dGVzIChzZXQgYnkgUHJpbnRlcikHBwcH CQkJY3VycmVudC1qb2Itc3RhdGUHdHlwZSAxIGVudW0HcwcHCQkJcHJpbnRlci1hc3NpZ25lZCAg WyBsZXSScyBrZWVwIGl0IHNpbXBsZSBdB25hbWUHcwcHCQkJc3VibWlzc2lvbi10aW1lB2RhdGUv dGltZQdzBwcJCQlqb2ItbWVzc2FnZS1mcm9tLWFkbWluaXN0cmF0b3IHc3RyaW5nB3MHBwkJCWNv bXBsZXRpb24tdGltZQdkYXRlL3RpbWUHcwcHCQkJam9iLXN0YXRlLXJlYXNvbnMHdHlwZSAyIGVu dW0HbQcHCQkJaW1wcmVzc2lvbnMtY29tcGxldGVkB2NhcmRpbmFsB3MHBwkJCW1lZGlhLXNoZWV0 cy1jb21wbGV0ZWQHY2FyZGluYWwHcwcHCQlKb2Igc2hlZXQgIEF0dHJpYnV0ZXMgKHNldCBieSBj bGllbnQpBwcHBwkJCWpvYi1zaGVldHMHdHlwZSAzIGVudW0HcwcHCQlKb2IgRXZlbnQgSGFuZGxp bmcgQXR0cmlidXRlcyAoc2V0IGJ5IGNsaWVudCkHBwcHCQkJbm90aWZpY2F0aW9uLWV2ZW50c3By b2ZpbGUgKHR3byBjbGFzc2VzIG9mIGV2ZW50cywgZGVsaXZlcnkgB3R5cGUgMiBlbnVtB20HBwkJ CW5vdGlmaWNhdGlvbi1hZGRyZXNzZXMgKG1ldGhvZHMgb3RoZXIgdGhhbiBlbWFpbCBhcmUgYSBw cm9ibGVtIHdpdGggaW50ZXJuZXQpB3N0cmluZwdtBwcJCUpvYiBTY2hlZHVsaW5nIEluc3RydWN0 aW9ucyBBdHRyaWJ1dGVzIChzZXQgYnkgY2xpZW50KQcHBwcJCQlqb2ItaG9sZAdib29sZWFuB3MH BwkJCWpvYi1wcmlvcml0eQd0eXBlIDIgZW51bQdzBwcJCQlqb2ItcHJpbnQtYWZ0ZXIHZGF0ZS90 aW1lB3MHBwkJCUpvYi1wcmludC1vZmYtcGVhawd0eXBlIDMgZW51bQdzBwcJCQlqb2ItcmV0ZW50 aW9uLXBlcmlvZAdjYXJkaW5hbAdzBwcJRG9jdW1lbnQgRGVzY3JpcHRpb24gQXR0cmlidXRlBwcH BwkJCWRvY3VtZW50LWZvcm1hdAkJCQd0eXBlIDIgZW51bQdzBwcJRG9jdW1lbnQgUHJvZHVjdGlv biBJbnN0cnVjdGlvbiBBdHRyaWJ1dGVzIChzZXQgYnkgY2xpZW50KQcHBwcJCQlkb2N1bWVudC1m b3JtYXQHdHlwZSAyIGVudW0HcwcHCQkJbWVkaXVtLXNlbGVjdAd0eXBlIDIgZW51bQdzBwcJCQlu dW1iZXItdXAHdHlwZSAyIGVudW0HcwcHCQkJZmluaXNoaW5nB3R5cGUgMiBlbnVtB3MHBwkJCXNp ZGVzB3R5cGUgMiBlbnVtB3MHBwkJCWNvcGllcwdvcmRpbmFsB3MHBwkJCXByaW50ZXItcmVzb2x1 dGlvbi1zZWxlY3QHb3JkaW5hbCBwYWlyB3MHBwkJCXByaW50LXF1YWxpdHkHdHlwZSAyIGVudW0H cwcHCQkJcGFnZS1zZWxlY3QHb3JkaW5hbCBwYWlyB3MHBwkJQXR0cmlidXRlcyBmb3IgQ29udmVy c2lvbiBvZiBUZXh0IEZpbGVzIChzZXQgYnkgY2xpZW50KQcHBwcJCQl3aWR0aAdvcmRpbmFsB3MH BwkJCWxlbmd0aAdvcmRpbmFsB3MHBwkJCWxlZnQtbWFyZ2luB2NhcmRpbmFsB3MHBwkJCXJpZ2h0 LW1hcmdpbgdjYXJkaW5hbAdzBwcJCQl0b3AtbWFyZ2luB2NhcmRpbmFsB3MHBwkJCWJvdHRvbS1t YXJnaW4HY2FyZGluYWwHcwcHCQkJcmVwZWF0ZWQtdGFiLXN0b3BzB29yZGluYWwHcwcHCQkJaGVh ZGVyLXRleHQHc3RyaW5nB3MHBwkJCWZvb3Rlci10ZXh0B3N0cmluZwdzBwcJCQludW1iZXItcGFn ZXMHYm9vbGVhbgdzBwcJCQlkZWZhdWx0LWZvbnQHc3RyaW5nB3MHBwkJCWRlZmF1bHQtY2hhcmFj dGVyLXNldAd0eXBlIDIgZW51bQdzBwcJCQljb250ZW50LW9yaWVudGF0aW9uBwdzBwcJCUpvYiBS ZXNvdXJjZSAgQXR0cmlidXRlcyAoc2V0IGJ5IHByb2Nlc3Mgd2hpY2ggcHJvZHVjZXMgUERMIGZp bGU7IGZvciB1c2UgaW4gc2NoZWR1bGluZykgBwcHBwkJCWRvY3VtZW50LWZvcm1hdHMtdXNlZAd0 eXBlIDIgZW51bQdtBwcJCQlmb250cy11c2VkB3N0cmluZwdtBwcJCQljaGFyYWN0ZXItc2V0cy11 c2VkB3R5cGUgMiBlbnVtB20HBwkJCW1lZGlhLXVzZWQHdHlwZSAyIGVudW0HbQcHCQkJc2lkZXMt dXNlZAd0eXBlIDIgZW51bQdzBwcJCQlwcmludC1xdWFsaXR5LXVzZWQHdHlwZSAyIGVudW0HcwcH CQkJZmluaXNoaW5ncy11c2VkB3R5cGUgMiBlbnVtB20HBwkJCXByaW50ZXItcmVzb2x1dGlvbi11 c2VkB29yZGluYWwgcGFpcgdzBwcJCQl0b3RhbC1qb2Itb2N0ZXRzB2NhcmRpbmFsB3MHBwkJCWpv Yi1pbXByZXNzaW9uLWNvdW50B2NhcmRpbmFsB3MHBwkJCWpvYi1tZWRpYS1zaGVldC1jb3VudAdj YXJkaW5hbAdzBwcJRG9jdW1lbnQgQ29udGVudHMgKG9uZSBwZXIgZG9jdW1lbnQpBwcHBwkJbnVt YmVyLW9mLWRvY3VtZW50cwdjYXJkaW5hbAdzBwcJCWRvY3VtZW50LWNvbnRlbnQgKGFjdHVhbCBj b250ZW50cyBvciBhIHBhdGggcmVmZXJlbmNlKQ1JU1NVRSAtIG9yIG1ha2UgdHdvIGF0dHJpYnV0 ZXM/B29jdGV0IHN0cmluZyBvciB1cmwHbT8HBwlPcGVyYXRpb24gQXR0cmlidXRlcwcHBwcJCW9w ZXJhdGlvbi1sb2NhbGUHdHlwZSAyIGVudW0HcwcHCQlkZWZhdWx0LWRlbGl2ZXJ5LWFkZHJlc3Nl cwdzdHJpbmcHbQcHUHJpbnRlciBBdHRyaWJ1dGVzIChQcmludCBTZXJ2ZXJzIGFuZCBPdXRwdXQg RGV2aWNlcykHBwcHCQlwcmludGVyLW5hbWUHbmFtZQdzBwcJCXByaW50ZXItbG9jYXRpb24Hc3Ry aW5nB3MHBwkJcHJpbnRlci1tb2RlbAdzdHJpbmcHcwcHCQlwcmludGVyLXR5cGVzB3R5cGUgMiBl bnVtB20HBwkJcHJpbnRlci1zdGF0ZQd0eXBlIDEgZW51bQdzBwcJCXByaW50ZXItc3RhdGUtbWVz c2FnZQdzdHJpbmcHcwcHCQltZXNzYWdlB3N0cmluZwdzBwcJCW5vdGlmaWNhdGlvbi1ldmVudHNw cm9maWxlB3R5cGUgMiBlbnVtB20HBwkJbm90aWZpY2F0aW9uLWFkZHJlc3NlcwdzdHJpbmcHbQcH CQlhY2Nlc3MtY29udHJvbC1saXN0BwcHBwkJZm9udHMtc3VwcG9ydGVkB3N0cmluZwdtBwcJCWZv bnQtc3Vic3RpdHV0aW9ucy1zdXBwb3J0ZWQHc3RyaW5nIHBhaXJzB20HBwkJbWVkaWEtc3VwcG9y dGVkB3R5cGUgMiBlbnVtB20HBwkJZG9jdW1lbnQtZm9ybWF0cy1zdXBwb3J0ZWQHdHlwZSAyIGVu dW0HbQcHCQludW1iZXJzLXVwLXN1cHBvcnRlZAd0eXBlIDIgZW51bQdtBwcJCWZpbmlzaGluZ3Mt c3VwcG9ydGVkB3R5cGUgMiBlbnVtB20HBwkJc2lkZXMtc3VwcG9ydGVkB3R5cGUgMiBlbnVtB20H BwkJcHJpbnQtcXVhbGl0aWVzLXN1cHBvcnRlZAd0eXBlIDIgZW51bQdtBwcJCW1heGltdW0tcHJp bnRlci1zcGVlZAdzdHJpbmcgdW5pdHMHcwcHCQlwcmludGVyLXJlc29sdXRpb25zLXN1cHBvcnRl ZAdzdHJpbmcgdW5pdHMHbQcHCQlkZWxpdmVyeS1tZXRob2RzLXN1cHBvcnRlZAcHBwcJCWNoYXJh Y3Rlci1zZXRzLXN1cHBvcnRlZAd0eXBlIDIgZW51bQdtBwcJCWpvYi1zaGVldHMtc3VwcG9ydGVk B3R5cGUgMiBlbnVtB20HBwkJbWF4aW11bS1jb3BpZXMtc3VwcG9ydGVkB29yZGluYWwHcwcHCQlt YXhpbXVtLWpvYi1vY3RldHMHb3JkaW5hbAdzBwcJCW1heGltdW0tam9iLXJldGVudGlvbi1wZXJp b2QHY2FyZGluYWwHcwcHCQltYXhpbXVtLWVuZC11c2VyLWpvYi1wcmlvcml0eQdvcmRpbmFsB3MH BwkJbWF4aW11bS1pbXByZXNzaW9ucwdvcmRpbmFsB3MHBwkJbWF4aW11bS1tZWRpYS1zaGVldHMH b3JkaW5hbAdzBwcJCW9mZi1wZWFrLXRpbWVzLXN1cHBvcnRlZAd0eXBlIDIgZW51bQdtBwcJCW5v dGlmaWNhdGlvbi1kZWxpdmVyeS1tZXRob2RzLXN1cHBvcnRlZAcHBwcJCWRvd25zdHJlYW0tcHJp bnRlcnMHbmFtZQdtBwcJCW5vdGlmaWNhdGlvbi1ldmVudHMtc3VwcG9ydGVkB3R5cGUgMiBlbnVt B20HBwkJbG9jYWxlcy1zdXBwb3J0ZWQ/Pwd0eXBlIDIgZW51bQdtBwcJCWxvY2FsZT8/B3R5cGUg MiBlbnVtB3MHBwkJc2hlZXQtY291bnQHBwcHCQlwcmludGVyLXRpbWVvdXQtcGVyaW9kBwcHBwcH BwcJSm9iIFRlbXBsYXRlIChhdHRyaWJ1dGVzIGZyb20gdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBv ZiBKb2IpBwcHBwkJSm9iIHNoZWV0ICBBdHRyaWJ1dGVzBwcHBwkJSm9iIEV2ZW50IEhhbmRsaW5n IEF0dHJpYnV0ZXMgBwcHBwkJSm9iIFNjaGVkdWxpbmcgSW5zdHJ1Y3Rpb25zIEF0dHJpYnV0ZXMH BwcHCQkJZXhjZXB0IG5vdCBqb2ItcHJpbnQtYWZ0ZXIHBwcHCQlEb2N1bWVudCBQcm9kdWN0aW9u IEluc3RydWN0aW9uIEF0dHJpYnV0ZXMHBwcHCQlBdHRyaWJ1dGVzIGZvciBDb252ZXJzaW9uIG9m IFRleHQgRmlsZXMHBwcHDQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ1UaGUgZm9sbG93aW5nIGlzIHRoZSBsaXN0 IG9mIGF0dHJpYnV0ZXMgd2l0aCByZXZpc2lvbnMgYXMgdGhleSBhcHBlYXJlZCBpbiB0aGUgTm92 IDExLCAxOTk2IDAuOSB2ZXJzaW9uIHRoYXQgQm9iIEhlcnJpb3QgcHJvZHVjZWQ6DQ1UaGlzIHNl Y3Rpb24gZGVzY3JpYmVzIHRoZSBhdHRyaWJ1dGVzIGFuZCB0aGVpciBhc3NvY2lhdGVkIHZhbHVl cyB0aGF0IGFyZSBwYXJ0IG9mIHRoZSBMRFBBIHByb3RvY29sLiBUaGUgbGlzdCBiZWxvdyBzaG93 cyB0aGUgb2JqZWN0cyBhbmQgdGhlaXIgYXR0cmlidXRlcyB0aGF0IGFyZSBpbmNsdWRlZCB3aXRo aW4gdGhlIHNjb3BlIG9mIHRoaXMgcHJvdG9jb2w6DQ0NSm9iIEF0dHJpYnV0ZXMNCQlKb2IgSW5m b3JtYXRpb25hbCBBdHRyaWJ1dGVzIChzZXQgYnkgY2xpZW50KQ0JCQlqb2ItaWRlbnRpZmllcg0J CQlqb2Itb3duZXJvcmlnaW5hdG9yIChhbiBhdXRoZW50aWNhdGVkIHZhbHVlKQ0JCQlqb2ItbmFt ZQ0JCQlqb2Itb3JpZ2luYXRpbmctaG9zdA0JCUpvYiBJbmZvcm1hdGlvbmFsIEF0dHJpYnV0ZXMg KHNldCBieSBQcmludGVyKQ0JCQlqb2ItaWRlbnRpZmllcg0JCQlqb2ItaWRlbnRpZmllci1vbi1v dXRwdXQtZGV2aWNlICh1c2VkIGJ5IG9wZXJhdG9yKQ0JCVByaW50ZXIgU2VsZWN0aW9uIEF0dHJp YnV0ZXMgKHNldCBieSBjbGllbnQpDQkJCXByaW50ZXItbmFtZS1yZXF1ZXN0ZWQNCQkJb3V0cHV0 LWRldmljZS1yZXF1ZXN0ZWQNCQlKb2IgU3RhdHVzIEF0dHJpYnV0ZXMgKHNldCBieSBQcmludGVy KQ0JCQljdXJyZW50LWpvYi1zdGF0ZQ0JCQlwcmludGVycy1hc3NpZ25lZCAgWyBsZXSScyBrZWVw IGl0IHNpbXBsZSBdDQkJCXN1Ym1pc3Npb24tdGltZQ0JCQlwcmludC1jaGVja3BvaW50DQkJCWpv Yi1tZXNzYWdlLWZyb20tYWRtaW5pc3RyYXRvcg0JCQljb21wbGV0aW9uLXRpbWUNCQkJam9iLXN0 YXRlLXJlYXNvbnMNCQkJaW1wcmVzc2lvbnMtY29tcGxldGVkDQkJCW1lZGlhLXNoZWV0cy1jb21w bGV0ZWQNCQkJbnVtYmVyLW9mLWRvY3VtZW50cw0JCQlqb2Itc3VibWlzc2lvbi1jb21wbGV0ZQ0J CUpvYiBzaGVldCBKb2IgUmVzdWx0cyBIYW5kbGluZyBBdHRyaWJ1dGVzIChzZXQgYnkgY2xpZW50 KQ0JCQlqb2Itc2hlZXRzDQkJCWRvY3VtZW50LXNoZWV0cw0JCUpvYiBFdmVudCBIYW5kbGluZyBB dHRyaWJ1dGVzIChzZXQgYnkgY2xpZW50KQ0JCQlub3RpZmljYXRpb24tcHJvZmlsZSAodHdvIGNs YXNzZXMgb2YgZXZlbnRzLCBkZWxpdmVyeSANCQkJCQltZXRob2RzIG90aGVyIHRoYW4gZW1haWwg YXJlIGEgcHJvYmxlbSB3aXRoIGludGVybmV0KQ0JCUpvYiBTY2hlZHVsaW5nIEluc3RydWN0aW9u cyBBdHRyaWJ1dGVzIChzZXQgYnkgY2xpZW50KQ0JCQlqb2ItaG9sZA0JCQlqb2ItcHJpb3JpdHkN CQkJam9iLXByaW50LWFmdGVyDQkJCUpvYi1wcmludC1vZmYtcGVhaw0JCQlqb2ItcmV0ZW50aW9u LXBlcmlvZA0JRG9jdW1lbmV0IEF0dHJpYnV0ZXMNCURvY3VtZW50IERlc2NyaXB0aW9uIEF0dHJp YnV0ZQ0JCQlkb2N1bWVudC1mb3JtYXQNCQkJZG9jdW1lbnQtY29udGVudA0JCQl0cmFuc2Zlci1t ZXRob2QNCQlEb2N1bWVudCBQcm9kdWN0aW9uIEluc3RydWN0aW9uIEF0dHJpYnV0ZXMgKHNldCBi eSBjbGllbnQpDQkJCWRvY3VtZW50LWZvcm1hdA0JCQlkZWZhdWx0LWZvbnQNCQkJc2VmYXVsdC1t ZWRpdW0tc2VsZWN0DQkJCW51bWJlci11cA0JCQlmaW5pc2hpbmcNCQkJc2lkZXMNCQkJY29waWVz Y29weS1jb3VudA0JCQlyZXNldC1wcmludGVyDQkJCXByaW50ZXItcmVzb2x1dGlvbi1zZWxlY3QN CQkJcHJpbnQtcXVhbGl0eQ0JCQlwYWdlLXNlbGVjdA0JCUF0dHJpYnV0ZXMgZm9yIENvbnZlcnNp b24gb2YgVGV4dCBGaWxlcyAoc2V0IGJ5IGNsaWVudCkNCQkJd2lkdGgNCQkJbGVuZ3RoDQkJCWxl ZnQtbWFyZ2luDQkJCXJpZ2h0LW1hcmdpbg0JCQl0b3AtbWFyZ2luDQkJCWJvdHRvbS1tYXJnaW4N CQkJcmVwZWF0ZWQtdGFiLXN0b3BzDQkJCWhlYWRlci10ZXh0DQkJCWZvb3Rlci10ZXh0DQkJCW51 bWJlci1wYWdlcw0JCQlkZWZhdWx0LWZvbnQNCQkJZGVmYXVsdC1jaGFyYWN0ZXItc2V0DQkJCWNv bnRlbnQtb3JpZW50YXRpb24NCQlKb2IgUmVzb3VyY2UgRG9jdW1lbnQgQ2hhcmFjdGVyaXN0aWNz IEF0dHJpYnV0ZXMgKHNldCBieSANCQkJCXByb2Nlc3Mgd2hpY2ggcHJvZHVjZXMgUERMIGZpbGU7 IGZvciB1c2UgaW4gc2NoZWR1bGluZykgDQkJCWRvY3VtZW50LWZvcm1hdC11c2VkDQkJCWZvbnRz LXVzZWQNCQkJY2hhcmFjdGVyLXNldHMtdXNlZA0JCQltZWRpYS11c2VkDQkJCXNpZGVzLXVzZWQN CQkJcHJpbnQtcXVhbGl0eS11c2VkDQkJCWZpbmlzaGluZy11c2VkDQkJCXByaW50ZXItcmVzb2x1 dGlvbi11c2VkDQkJCXRvdGFsLWpvYi1vY3RldHMNCQkJam9iLWltcHJlc3Npb24tY291bnQNCQkJ am9iLW1lZGlhLXNoZWV0LWNvdW50DQkJRG9jdW1lbnQgU3RhdHVzIEF0dHJpYnV0ZXMNCQkJZG9j dW1lbnQtc2VxdWVuY2UtbnVtYmVyDQlEb2N1bWVudCBDb250ZW50cyAob25lIHBlciBkb2N1bWVu dCkNCQludW1iZXItb2YtZG9jdW1lbnRzDQkJZG9jdW1lbnQtY29udGVudCAoYWN0dWFsIGNvbnRl bnRzIG9yIGEgcGF0aCByZWZlcmVuY2UpDQlPcGVyYXRpb24gQXR0cmlidXRlcw0JCW9wZXJhdGlv bi1sb2NhbGUNCQlkZWZhdWx0LWRlbGl2ZXJ5LWFkZHJlc3Nlcw0JUHJpbnRlciBBdHRyaWJ1dGVz IChQcmludCBTZXJ2ZXJzIGFuZCBPdXRwdXQgRGV2aWNlcykNCQlwcmludGVyLW5hbWUNCQlwcmlu dGVyLWxvY2F0aW9uDQkJcHJpbnRlci1tb2RlbA0JCXByaW50ZXItdHlwZXMNCQlwcmludGVyLXN0 YXRlDQkJcHJpbnRlci1zdGF0ZS1tZXNzYWdlDQkJbWVzc2FnZQ0JCW5vdGlmaWNhdGlvbi1wcm9m aWxlDQkJYWNjZXNzLWNvbnRyb2wtbGlzdA0JCXByaW50ZXItaW5pdGlhbC12YWx1ZS1qb2INCQlw cmludGVyLWluaXRpYWwtdmFsdWUtZG9jdW1lbnQNCQlmb250cy1zdXBwb3J0ZWQNCQlmb250LXN1 YnN0aXR1dGlvbnMNCQlmb250cy1yZWFkeQ0JCW1lZGlhLXN1cHBvcnRlZA0JCW1lZGlhLXJlYWR5 DQkJcHJpbnRlci1hc3NvY2lhdGVkLXByaW50ZXJzDQkJZG9jdW1lbnQtZm9ybWF0cy1zdXBwb3J0 ZWQNCQludW1iZXJzLXVwLXN1cHBvcnRlZA0JCWZpbmlzaGluZ3Mtc3VwcG9ydGVkDQkJc2lkZXMt c3VwcG9ydGVkDQkJcHJpbnQtcXVhbGl0aWVzLXN1cHBvcnRlZA0JCW1heGltdW0tcHJpbnRlci1z cGVlZA0JCXByaW50ZXItcmVzb2x1dGlvbnMtc3VwcG9ydGVkDQkJZGVsaXZlcnktbWV0aG9kcy1z dXBwb3J0ZWQNCQljaGFyYWN0ZXItc2V0cy1zdXBwb3J0ZWQNCQlqb2Itc2hlZXRzLXN1cHBvcnRl ZA0JCWRvY3VtZW50LXNoZWV0cy1zdXBwb3J0ZWQNCQltYXhpbXVtLWNvcGllcy1zdXBwb3J0ZWQN CQltYXhpbXVtLWpvYi1vY3RldHMNCQltYXhpbXVtLWpvYi1yZXRlbnRpb24tcGVyaW9kDQkJbWF4 aW11bS1qb2ItcHJpb3JpdHkNCQltYXhpbXVtLWltcHJlc3Npb25zDQkJbWF4aW11bS1tZWRpYS1z aGVldHMNCQlvZmYtcGVhay10aW1lcw0JCW5vdGlmaWNhdGlvbi1kZWxpdmVyeS1tZXRob2RzLXN1 cHBvcnRlZA0JCXNlcnZlci1uYW1lDQkJc2VydmVyLXN0YXRlDQkJZG93bnN0cmVhbS1wcmludGVy cw0JCXBoeXNpY2FsLXByaW50ZXJzLXN1cHBvcnRlZA0JCWxvZ2ljYWwtcHJpbnRlcnMtc3VwcG9y dGVkDQkJZXZlbnRzLXN1cHBvcnRlZA0JCXRyYW5zZmVyLW1ldGhvZHMtc3VwcG9ydGVkDQkJbG9j YWxlcy1zdXBwb3J0ZWQNCQlsb2NhbGUNCQltdWx0aXBsZS1kb2N1bWVudHMtc3VwcG9ydGVkDQkJ Y2FuY2VsLWluZGl2aWR1YWwtZG9jdW1lbnQtc3VwcG9ydGVkDQkJbW9kaWZ5LWluZGl2aWR1YWwt ZG9jdW1lbnQtc3VwcG9ydGVkIA0JCXNoZWV0LWNvdW50DQkJcHJpbnRlci10aW1lb3V0LXBlcmlv ZA0JSW5pdGlhbCBWYWx1ZSBKb2IgQXR0cmlidXRlcw0JSW5pdGlhbCBWYWx1ZSBEb2N1bWVudCBB dHRyaWJ1dGVzDQlKb2IgVGVtcGxhdGUgKGF0dHJpYnV0ZXMgZnJvbSB0aGUgZm9sbG93aW5nIHNl Y3Rpb25zIG9mIEpvYikNCQlKb2Igc2hlZXQgIEF0dHJpYnV0ZXMNCQlKb2IgRXZlbnQgSGFuZGxp bmcgQXR0cmlidXRlcyANCQlKb2IgU2NoZWR1bGluZyBJbnN0cnVjdGlvbnMgQXR0cmlidXRlcw0J CURvY3VtZW50IFByb2R1Y3Rpb24gSW5zdHJ1Y3Rpb24gQXR0cmlidXRlcw0JCUF0dHJpYnV0ZXMg Zm9yIENvbnZlcnNpb24gb2YgVGV4dCBGaWxlcw0NDQgAmAKaAQCrAQDQzxHgobEa4QAAAAAAAAAA AAAAAAAAAAA7AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAQAAACAAAAAQAAAP7///8A AAAAAAAAAP////////////////////////////8FAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAP///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhhc3RpbmdzAAAAAAAAAAAAAAAAAAAAAEAAAACG rTwGHNO7AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACG5eZJI9O7AQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAACGK6ptI9O7AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAACZBAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAA4GgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAAAAfm1nBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAATAAAATWljcm9zb2Z0 IFdvcmQgNi4wAAAAAAAAAAAAAAMAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4A AAACAAAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AAMAAA8LAAAQCwAAFgsAABcLAAAaCwAAHAsAACoL AAArCwAALQsAAC4LAABcCwAAXQsAAF8LAABgCwAAigsAAIsLAACRCwAAkgsAAJMLAACUCwAAlQsA AKALAAChCwAApwsAAKgLAACpCwAAqgsAAKsLAADCCwAAwwsAAMULAADGCwAA9QsAAPYLAAD4CwAA +QsAAAoMAAALDAAADwwAABAMAAARDAAAEgwAABMMAABIDAAASQwAAE0MAABODAAATwwAAFAMAABR DAAAfwwAAIAMAACCDAAAgwwAAJwMAACdDAAAoQwAAKIMAACjDAAApAwAAKUMAAC/DAAAwAwAAMIM AADDDAAA6wwAAOwMAADuDAAA7wwAAAMNAAAEDQAADw0AABANAAARDQAAEg0AABMNAABADQAAQQ0A AEUNAABGDQAARw0AAEgNAABJDQAAWw0AAFwNAABlDQAAZg0AAGcNAABoDQAAaQ0AAIoNAACLDQAA APoA+gD6APTu9AD07vQA9ADuAO70APQA7gDu9Oj07vQA9O70APQA7gDu9AD0AO4A7vQA9O70APQA 7gDu9Oj07vQA9O70APQA7gDu9AD0AO4A7vQA9ADuAO70APQKQYFFAQBGXnwLpgAKQoFFAQBGanwL pgAKQoFFAQBGaXwLpgAKQoFFAQBGa3wLplyLDQAAkQ0AAJINAACTDQAAlA0AAJUNAACnDQAAqA0A ALENAACyDQAAsw0AALQNAAC1DQAAyQ0AAMoNAADVDQAA1g0AANcNAADYDQAA2Q0AAPENAADyDQAA +g0AAPsNAAD8DQAA/Q0AAP4NAAAXDgAAGA4AACAOAAAhDgAAIg4AACMOAAAkDgAASw4AAEwOAABO DgAATw4AAFwOAABdDgAAaA4AAGkOAABqDgAAaw4AAGwOAACbDgAAnA4AAJ4OAACfDgAArw4AALUO AAC8DgAA3g4AAN8OAADqDgAA6w4AAOwOAADtDgAA7g4AAAcPAAA+DwAAPw8AAEUPAABGDwAARw8A AEkPAACBDwAAgg8AAIQPAACFDwAAkA8AAJEPAACYDwAAmQ8AAJoPAACbDwAAnA8AAKsPAACsDwAA tw8AALgPAAC5DwAAug8AALsPAAC+DwAAzQ8AAM4PAADXDwAA2A8AANkPAAAA+gD69AD0APoA+vQA 9AD6APr0APQA+gD69AD0APoA+vQA9Pr0APQA+gD69AD0+vQA7ugA9AD6APr07gDuAO4A7gD0+vQA 9AD6APr0APQA+gD69ADi9AD6AAAAAApCgUUBAEZffAumAApBgUUBAEaCfAumAApCgUUBAEaCfAum AApCgUUBAEZpfAumAApCgUUBAEZqfAumWdkPAADaDwAA2w8AAPAPAADxDwAA/A8AAP0PAAD+DwAA /w8AAAAQAAAXEAAAGBAAACAQAAAhEAAAIhAAACMQAAAkEAAAQxAAAEQQAABGEAAARxAAAFwQAABd EAAAaBAAAGkQAABqEAAAaxAAAGwQAACnEAAAqBAAAKoQAACrEAAAvRAAAL4QAADJEAAAyhAAAMsQ AADMEAAAzRAAAN0QAADeEAAA6RAAAOoQAADrEAAA7BAAAO0QAAD5EAAA+hAAAAURAAAGEQAABxEA AAgRAAAJEQAAFREAABYRAAAhEQAAIhEAACMRAAAkEQAAJREAAC0RAAAuEQAAOREAADoRAAA7EQAA PBEAAD0RAABGEQAARxEAAE4RAABPEQAAUBEAAFERAABSEQAAbhEAAG8RAAB7EQAAfBEAAH0RAAB+ EQAAfxEAAI8RAACQEQAAmxEAAJwRAACdEQAAnhEAAJ8RAACtEQAArhEAALoRAAC7EQAAvBEAAL0R AAC+EQAA9xEAAPgRAAD69AD0APoA+vQA9AD6APr0APT69AD0APoA+vQA9Pr0APQA+gD69AD0APoA +vQA9AD6APr0APQA+gD69AD0APoA+vQA9AD6APr0APQA+gD69AD0APoA+vQA9AD6APr0APQAAAAA CkKBRQEARml8C6YACkKBRQEARmp8C6Zg+BEAAPoRAAD7EQAAAxIAAAQSAAALEgAADBIAAA0SAAAO EgAADxIAABgSAAAZEgAAIBIAACESAAAiEgAAIxIAACQSAAAyEgAAMxIAADsSAAA8EgAAPRIAAD4S AAA/EgAAThIAAE8SAABXEgAAWBIAAFkSAABaEgAAWxIAAGgSAABpEgAAcRIAAHISAABzEgAAdBIA AHUSAACFEgAAhhIAAI4SAACPEgAAkBIAAJESAACSEgAApxIAAKgSAACvEgAAsBIAALESAACyEgAA sxIAAMESAADCEgAAyBIAAMkSAADKEgAAyxIAAMwSAADaEgAA2xIAAOESAADiEgAA4xIAAOQSAADl EgAA9BIAAPUSAAD8EgAA/RIAAP4SAAD/EgAAABMAAA8TAAAQEwAAFhMAABcTAAAYEwAAGRMAABoT AAAyEwAAMxMAAD4TAAA/EwAAQBMAAEETAABCEwAAWBMAAFkTAABaEwAAWxMAAFwTAABdEwAAuBMA ALkTAAC7EwAAvBMAAPr0APQA+gD69AD0APoA+vQA9AD6APr0APQA+gD69AD0APoA+vQA9AD6APr0 APQA+gD69AD0APoA+vQA9AD6APr0APQA+gD69AD0APoA+vQA9AD6APr0APT6APr0APT69AAAAAAK QoFFAQBGaXwLpgAKQoFFAQBGanwLpmC8EwAAzhMAAM8TAADUEwAA1RMAAOATAADhEwAA4hMAAOMT AADkEwAA8RMAAPITAAD4EwAA+RMAAPoTAAD7EwAA/BMAABIUAAATFAAAHhQAAB8UAAAgFAAAIRQA ACIUAAAvFAAAMBQAADsUAAA8FAAAPRQAAD4UAAA/FAAATBQAAE0UAABYFAAAWRQAAFoUAABbFAAA XBQAAHEUAAByFAAAfRQAAH4UAAB/FAAAgBQAAIEUAACNFAAAjhQAAJMUAACUFAAAnxQAAKAUAACh FAAAohQAAKMUAAC9FAAAvhQAAMoUAADLFAAAzBQAAM0UAADOFAAABRUAAAYVAAAOFQAADxUAABAV AAARFQAAEhUAACoVAAArFQAAMxUAADQVAAA1FQAANhUAADcVAABcFQAAXRUAAF8VAABgFQAAdRUA AHYVAAB+FQAAfxUAAIAVAACBFQAAghUAALoVAADaFQAA2xUAAO4VAAAA+gD0AO767vQA9ADuAO70 APQA7gDu9AD0AO4A7vQA9ADuAO70APQA7gDu9ADoAPQA7uju9AD0AO4A7vQA9ADuAO70APQA7gDu 9AD07vQA9ADuAO70AOL0AAAAAApCgUUBAEaPfAumAApCgUUBAEaafAumAApCgUUBAEZqfAumAApC gUUBAEZpfAumAApCgUUBAEaZfAumWe4VAADvFQAA8RUAAPIVAADzFQAACBYAAAkWAAALFgAADBYA AB4WAAAfFgAAKhYAACsWAAAsFgAALRYAAC4WAABKFgAASxYAAFEWAABSFgAAUxYAAFQWAABVFgAA ihYAAIsWAACNFgAAjhYAAJwWAACdFgAAoRYAAKIWAACjFgAApBYAAKUWAAC3FgAAuBYAAL4WAAC/ FgAAwBYAAMEWAADCFgAA0RYAANIWAADYFgAA2RYAANoWAADbFgAA3BYAAOsWAADsFgAA9xYAAPgW AAD5FgAA+hYAAPsWAAAKFwAACxcAABYXAAAXFwAAGBcAABkXAAAaFwAAMRcAADIXAAA4FwAAORcA ADoXAAA7FwAAPBcAAEUXAABGFwAATBcAAE0XAABOFwAATxcAAFAXAABfFwAAZRcAAGwXAABtFwAA eBcAAHkXAAB6FwAAexcAAHwXAACUFwAAlRcAAJsXAACcFwAAnRcAAJ4XAACfFwAA+gD69AD0+vQA 9AD6APr0APQA+gD69AD0+vQA9AD6APr0APQA+gD69AD0APoA+vQA9AD6APr0APQA+gD69AD0APoA +vQA9AD6APr0AO7o9AD6APr07vQA+gD69AAAAAAACkGBRQEARmZ8C6YACkKBRQEARmZ8C6YACkKB RQEARml8C6YACkKBRQEARmp8C6ZbnxcAALQXAAC1FwAAtxcAALgXAADJFwAAyhcAANAXAADRFwAA 0hcAANMXAADUFwAA6BcAAPIXAADzFwAA/xcAAAAYAAABGAAAAhgAAAMYAAAUGAAAFRgAACAYAAAh GAAAIhgAACMYAAAkGAAAQBgAAEEYAABMGAAATRgAAE4YAABPGAAAUBgAAGYYAABnGAAAchgAAHMY AAB0GAAAdRgAAHYYAACMGAAAjRgAAJgYAACZGAAAmhgAAJsYAACcGAAArRgAAK4YAAC5GAAAuhgA ALsYAAC8GAAAvRgAANgYAADZGAAA5BgAAOUYAADmGAAA5xgAAOgYAAD/GAAAABkAAAwZAAANGQAA DhkAAA8ZAAAQGQAALxkAADAZAAA8GQAAPRkAAD4ZAAA/GQAAQBkAAFwZAABdGQAAXxkAAGAZAAB6 GQAAexkAAIYZAACHGQAAiBkAAIkZAACKGQAAoBkAAKEZAACsGQAArRkAAK4ZAACvGQAA+vTu9AD0 AO4A7vQA6PQA7gDu9AD0AO4A7vQA9ADuAO70APQA7gDu9AD0AO4A7vQA9ADuAO70APQA7gDu9AD0 AO4A7vQA9ADuAO70+vTu9AD0AO4A7vQA9ADuAO4KQoFFAQBGnXwLpgAKQoFFAQBGanwLpgAKQoFF AQBGaXwLpgAKQYFFAQBGZHwLplyvGQAAsBkAAMoZAADLGQAA0hkAANMZAADUGQAA1RkAANYZAADq GQAA6xkAAPIZAADzGQAA9BkAAPUZAAD2GQAAFBoAABUaAAAdGgAAHhoAAB8aAAAgGgAAIRoAACsa AAA0GgAAQBoAAEEaAABIGgAASRoAAEoaAABLGgAATBoAAGEaAABiGgAAaRoAAGoaAABrGgAAbBoA AG0aAACDGgAAhBoAAIsaAACMGgAAjRoAAI4aAACPGgAAnxoAAKkaAACqGgAAtRoAALYaAAC3GgAA uBoAALkaAADiGgAA4xoAAOUaAADmGgAA+xoAAPwaAAAAGwAAARsAAAIbAAADGwAABBsAAAYbAAAT GwAAIxsAACQbAAAvGwAAMBsAADEbAAAyGwAAMxsAAEYbAABIGwAASRsAAFQbAABVGwAAVhsAAFcb AABYGwAAYBsAAGIbAABjGwAAbhsAAG8bAABwGwAA+gD6APQA9PoA+gD0APT6APoA9AD0+gDuAPoA 9AD0+gD6APQA9PoA+gD0APT6AO76APQA9Pro+vT6APoA9AD0+gDiAPoA9AD0+gDc+gD0APT6ANz6 APQAAApCgUUBAEZnfAumAApCgUUBAEZmfAumAApBgUUBAEZlfAumAApCgUUBAEZlfAumAApCgUUB AEZqfAumAApCgUUBAEZpfAumV3AbAABxGwAAchsAAH8bAACAGwAAghsAAIMbAACbGwAAnBsAAJ4b AACgGwAAohsAAKMbAADgGwAA4RsAAOMbAADkGwAA+xsAAPwbAAD+GwAA/xsAAB8cAAAgHAAAIhwA ACMcAABLHAAATBwAAE4cAABPHAAAbBwAAG0cAABvHAAAcBwAAJwcAACdHAAAnxwAAKAcAADJHAAA yhwAAMwcAADNHAAAbB4AAG0eAACbHgAAqx4AAKweAAC9HgAAvh4AAMUeAADKHgAA7R4AAPkeAAD6 HgAA/R4AABEfAAASHwAAQh8AAGkfAACJHwAAih8AAKgfAAC4HwAA0h8AAO0fAAAFIAAA+vTu9Pr0 7vT69Pr0APT69AD0+vQA9Pr0APT69Oj0+vQA9Pr0APT69ADiANwA1tAAysQAvriyANzQrNAA0ACm AAAAAAAAAAAACkKBRQMARoRkC0YACkKBRQIARkRkC0YACkKBRQIARkhbCyYACkKBRQIARklbCyYA CkKBRQIARkdbCyYACkKBRQIARkBbCyYACkGBRQIARkBbCyYACkKBRQIARpxbCyYACkGBRQIARpxb CyYACkKBRQIARptbCyYACkKBRQIARmZbCyYACkKBRQEARmd8C6YACkGBRQEARmd8C6YACkKBRQEA Rml8C6YACkKBRQEARmp8C6ZABSAAABYgAAA2IAAANyAAAEAgAABaIAAAcSAAAIEgAADLIAAA/iAA AP8gAAAWIQAAGSEAADAhAAAzIQAAPCEAAD0hAABRIQAAXCEAAGwhAAB+IQAAjSEAAK0hAAC9IQAA 1SEAAOwhAAAxIgAAMiIAAFsiAABrIgAAiyIAAJoiAACeIgAAsCIAAMoiAADTIgAA3iIAABEjAAAS IwAAFSMAACUjAAApIwAAOCMAADojAAA7IwAAZSMAAHUjAAB2IwAAiSMAAPoA9ADuAPQA6ADiANwA 1tDKAPoAxAD6AL64vgD6ALKspgCgmgCaAJQAjgCIAPoAggAAAAAAAAAAAAAAAAAAAAAKQoFFAgBG GFwLJgAKQYFFAgBGnVsLJgAKQYFFAgBGTVsLJgAKQYFFAgBGZ1sLJgAKQYFFAgBGnlsLJgAKQYFF AgBGTFsLJgAKQoFFAgBGbFsLJgAKQoFFAgBGa1sLJgAKQYFFAgBGbFsLJgAKQoFFAwBGAmULRgAK QoFFAgBGS2QLRgAKQYFFAgBGR1sLJgAKQYFFAgBGjVsLJgAKQoFFAgBGjVsLJgAKQoFFAgBGqFwL JgAKQYFFAgBGRlsLJgAKQYFFAgBGhVsLJgAKQoFFAgBGl1sLJgAKQoFFAgBGRVsLJgAKQYFFAgBG RVsLJgAKQoFFAgBGnVsLJjCJIwAAmSMAAJwjAACkIwAAqiMAALEjAADYIwAA3iMAAOgjAADsIwAA +SMAABckAAAnJAAANiQAADckAAA5JAAASCQAAGAkAABwJAAAcSQAAPUkAAAFJQAABiUAABYlAABF JQAARiUAAEglAABVJQAAbSUAAHglAACBJQAAhiUAAKUlAAC8JQAAviUAAL8lAADRJQAA1iUAANcl AADlJQAA/CUAAAkmAAAXJgAAGCYAAFomAABbJgAA+gD0AO4A7vQA6OLc1tDKxMq+yriyuMSs+gCm oAC+mr6avgCmlKYAjgCIgnx2AAAAAAAAAApBgUUCAEaSWwsmAApCgUUCAEaRWwsmAApCgUUCAEaQ WwsmAApCgUUCAEZ1WwsmAApCgUUCAEaoWwsmAApCgUUCAEZ0WwsmAApCgUUCAEagWwsmAApBgUUC AEZuWwsmAApCgUUCAEZuWwsmAApCgUUCAEaUWwsmAApCgUUCAEZYXAsmAApCgUUCAEaTWwsmAApC gUUCAEafWwsmAApCgUUCAEaVWwsmAApCgUUCAEZtWwsmAApCgUUCAEamWwsmAApCgUUCAEaJWwsm AApCgUUCAEaIWwsmAApCgUUCAEaHWwsmAApBgUUCAEZOWwsmAApCgUUCAEZNWwsmAApBgUUCAEZN WwsmAApBgUUCAEZtWwsmLVsmAACgJgAAoiYAANgmAADZJgAA6yYAAP4mAAD/JgAAFScAABcnAABN JwAATicAAKcnAACpJwAAyScAAMonAADZJwAADCgAABwoAAAtKAAANCgAAD4oAABrKAAAbigAAIco AACKKAAAqCgAALooAADPKAAA0igAAN0oAADyKAAA/SgAAAApAAAbKQAAeCkAAJcpAADNKQAA6SkA AAQqAAAeKgAANyoAAFIqAABnKgAAnSoAAMoqAADcKgAACCsAABMrAAD6APQA7uju4u7c6ADW0NYA ygDEvgC4ALIAsgCsALIAsgCmAKCalKwApgCOiIJ8AKYAAAAACkKBRQIARhJcCyYACkKBRQIARrtb CyYACkKBRQIARrlbCyYACkKBRQIARrNbCyYACkKBRQIARrdbCyYACkKBRQIARrVbCyYACkKBRQIA RrRbCyYACkGBRQIARq5bCyYACkKBRQIARsBbCyYACkGBRQIARq1bCyYACkKBRQIARsFbCyYACkKB RQIARl1kC0YACkKBRQIARq1bCyYACkKBRQIARsJbCyYACkKBRQIARudkC0YACkKBRQIARttcCyYA CkKBRQIARqRbCyYACkKBRQIARo5cCyYACkKBRQIARthbCyYACkKBRQIARqNbCyYACkGBRQIARmZb CyYACkKBRQIARplbCyYwEysAABYrAAAiKwAAOCsAADsrAABWKwAAWSsAAHMrAACJKwAAoysAALcr AADAKwAAwysAAN8rAADiKwAABiwAAAksAAAtLAAALiwAAFUsAABWLAAAliwAAJcsAACkLAAANi0A AI0tAACOLQAAkC0AAJotAAAA+vQA+gD6APoA7gDoAOgA6ADiANzW0MrE3ADCAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAJ1AQAKQoFFAgBGqlwLJgAKQoFFAgBGqVwLJgAKQoFFAgBGplwLJgAKQoFFAgBG21wLJgAK QYFFAgBGplwLJgAKQoFFAgBGxFsLJgAKQYFFAgBGr1sLJgAKQoFFAgBGw1sLJgAKQoFFAwBGdGQL RgAKQYFFAgBGrlsLJhwAAwAAIwMAADcDAABKAwAAXQMAAF4DAACdAwAAngMAAOgDAAADBAAALgQA AHcEAACdBAAA4AQAAB0FAABfBQAAoAUAAOgFAAAsBgAASAYAAIgGAADQBgAAFwcAAFkHAACjBwAA 7QcAAAwIAABSCAAAmggAAOEIAAAbCQAAUAkAAIUJAAC1CQAA+gkAACQKAABRCgAAewoAALMKAAC0 CgAA/QoAAP4KAAD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHA IdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh 2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHY AP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA /gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/gABwCHYAP4AAcAh2AD+ AAHAIdgA/gABwCHYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAKf4KAAAQCwAAFwsAABsLAAAcCwAAKwsAACwLAAAtCwAALgsAAF0LAABeCwAA XwsAAGALAACLCwAAkgsAAJQLAACVCwAAoQsAAKgLAACqCwAAqwsAAMMLAADECwAAxQsAAMYLAAD2 CwAA9wsAAL0AAbYb2AC9AAF+BdgAvQABnQHYAKYAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACU AAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAlAABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAJQA AZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACUAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAlAAB nQHYAL0AAbYb2AC9AAF+BdgAAAAAAAAAEQAAGAEZAbhsALsJAAkACQAJAAkACQC+CgADlP8gHHQi 6iQAFgAAGAEZAbhsALoBuwkACQAJAAkACQAJAL4KAAOU/yAcdCLqJL8GAAwADAAMAEIAABgBMfAA MPAAD3cAJ8j7MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAh kCRgJzAqAC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAa9wsAAPgLAAD5CwAACwwAABAMAAASDAAAEwwAAEkMAABODAAAUAwAAFEMAACA DAAAgQwAAIIMAACDDAAAnQwAAKIMAACkDAAApQwAAMAMAADBDAAAwgwAAMMMAADsDAAA7QwAAO4M AADvDAAABA0AABANAAASDQAAEw0AAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgA qwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACr AAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsA AZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwAB nQHYAAAAAAAAAAAAEQAAGAEZAbhsALsJAAkACQAJAAkACQC+CgADlP8gHHQi6iQAQgAAGAEx8AAw 8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQ JGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAB4TDQAAQQ0AAEYNAABIDQAASQ0AAFwNAABmDQAAaA0AAGkNAACLDQAAkg0AAJQN AACVDQAAqA0AALINAAC0DQAAtQ0AAMoNAADWDQAA2A0AANkNAADyDQAA+w0AAP0NAAD+DQAAGA4A ACEOAAAjDgAAJA4AAEwOAABNDgAAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9 AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0A AX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQAB fgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+ BdgAAAAAAAAAAAARAAAYARkBuGwAuwkACQAJAAkACQAJAL4KAAOU/yAcdCLqJABCAAAYATHwADDw AA93ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAk YCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHk0OAABODgAATw4AAF0OAABpDgAAaw4AAGwOAACcDgAAnQ4AAJ4OAACfDgAA3w4A AOsOAADtDgAA7g4AAD8PAABGDwAASA8AAEkPAACCDwAAgw8AAIQPAACFDwAAkQ8AAJkPAACbDwAA nA8AAKwPAAC4DwAAug8AALsPAAC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsA AZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQACthvYAL0AAX4F2AC9AAGdAdgAqwAB nQHYAL0AArYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAK2G9gAvQABfgXYAL0AAZ0B2ACrAAGd AdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B 2AAAAAAAAAAAABEAABgBGQG4bAC7CQAJAAkACQAJAAkAvgoAA5T/IBx0IuokAEIAABgBMfAAMPAA D3cAJ8j7MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRg JzAqAC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAeuw8AAM4PAADYDwAA2g8AANsPAADxDwAA/Q8AAP8PAAAAEAAAGBAAACEQAAAjEAAA JBAAAEQQAABFEAAARhAAAEcQAABdEAAAaRAAAGsQAABsEAAAqBAAAKkQAACqEAAAqxAAAL4QAADK EAAAzBAAAM0QAADeEAAA6hAAAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQAB fgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+ BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQACthvYAL0AAX4F 2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXY AAAAAAAAAAAAEQAAGAEZAbhsALsJAAkACQAJAAkACQC+CgADlP8gHHQi6iQAQgAAGAEx8AAw8AAP dwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAn MCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAB7qEAAA7BAAAO0QAAD6EAAABhEAAAgRAAAJEQAAFhEAACIRAAAkEQAAJREAAC4RAAA6 EQAAPBEAAD0RAABHEQAATxEAAFERAABSEQAAbxEAAHwRAAB+EQAAfxEAAJARAACcEQAAnhEAAJ8R AACuEQAAuxEAAL0RAAC+EQAAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGd AdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B 2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAn4F2AC9AAGdAdgAqwABnQHY AL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQACfgXYAL0AAZ0B2ACrAAGdAdgA AAAAAAAAAAARAAAYARkBuGwAuwkACQAJAAkACQAJAL4KAAOU/yAcdCLqJABCAAAYATHwADDwAA93 ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcw KgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAHr4RAAD4EQAA+REAAPoRAAD7EQAABBIAAAwSAAAOEgAADxIAABkSAAAhEgAAIxIAACQS AAAzEgAAPBIAAD4SAAA/EgAATxIAAFgSAABaEgAAWxIAAGkSAAByEgAAdBIAAHUSAACGEgAAjxIA AJESAACSEgAAqBIAALASAAC9AAK2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F 2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXY AL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgA vQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AAA AAAAAAAAABEAABgBGQG4bAC7CQAJAAkACQAJAAkAvgoAA5T/IBx0IuokAEIAABgBMfAAMPAAD3cA J8j7MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAq AC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAesBIAALISAACzEgAAwhIAAMkSAADLEgAAzBIAANsSAADiEgAA5BIAAOUSAAD1EgAA/RIA AP8SAAAAEwAAEBMAABcTAAAZEwAAGhMAADMTAAA/EwAAQRMAAEITAABZEwAAWhMAAFwTAABdEwAA uRMAALoTAAC7EwAAvBMAAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHY AL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgA vQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9 AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQACthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAAAA AAAAAAAAEQAAGAEZAbhsALsJAAkACQAJAAkACQC+CgADlP8gHHQi6iQAQgAAGAEx8AAw8AAPdwAn yPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoA LdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAB68EwAA1RMAAOETAADjEwAA5BMAAPITAAD5EwAA+xMAAPwTAAATFAAAHxQAACEUAAAiFAAA MBQAADwUAAA+FAAAPxQAAE0UAABZFAAAWxQAAFwUAAByFAAAfhQAAIAUAACBFAAAlBQAAKAUAACi FAAAoxQAAL4UAADLFAAAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgA vQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9 AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0A AZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAJ+BdgAAAAA AAAAAAARAAAYARkBuGwAuwkACQAJAAkACQAJAL4KAAOU/yAcdCLqJABCAAAYATHwADDwAA93ACfI +zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt 0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAHssUAADNFAAAzhQAAOIUAADrFAAA7RQAAO4UAAAGFQAADxUAABEVAAASFQAAKxUAADQVAAA2 FQAANxUAAF0VAABeFQAAXxUAAGAVAAB2FQAAfxUAAIEVAACCFQAAuxUAANsVAADvFQAA8hUAAPMV AAAJFgAAChYAAAsWAAC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9 AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0A AbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQAC thvYAL0AAbYb2AC9AAN+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2AAAAAAA AAAAABEAABgBGQG4bAC7CQAJAAkACQAJAAkAvgoAA5T/IBx0IuokAEIAABgBMfAAMPAAD3cAJ8j7 MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAqAC3Q L6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAeCxYAAAwWAAAfFgAAKxYAAC0WAAAuFgAASxYAAFIWAABUFgAAVRYAAIsWAACMFgAAjRYAAI4W AACdFgAAohYAAKQWAAClFgAAuBYAAL8WAADBFgAAwhYAANIWAADZFgAA2xYAANwWAADsFgAA+BYA APoWAAD7FgAACxcAAO4AAZ0B2ACrAAG2G9gAqwABfgXYAKsAAZ0B2ADuAAGdAdgAqwABthvYAKsA AX4F2ACrAAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+BdgAqwABnQHYAO4AAZ0B2ACrAAG2G9gAqwAB fgXYAKsAAZ0B2ADuAAGdAdgAqwABthvYAKsAAX4F2ACrAAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+ BdgAqwABnQHYAO4AAZ0B2ACrAAG2G9gAqwABfgXYAKsAAZ0B2ADuAAGdAdgAqwABthvYAAAAAAAA AAAAQgAAGAEx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQ GbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAYARkBuGwAuwkACQAJAAkACQAJAL4KAAOU/yAcdCLq JB4LFwAAFxcAABkXAAAaFwAAMhcAADkXAAA7FwAAPBcAAEYXAABNFwAATxcAAFAXAABtFwAAeRcA AHsXAAB8FwAAlRcAAJwXAACeFwAAnxcAALUXAAC2FwAAtxcAALgXAADKFwAA0RcAANMXAADUFwAA 8xcAAAAYAAACGAAAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwAB nQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGd AdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B 2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAn4F2AC9AAGdAdgAAAAAAAAA AAARAAAYARkBuGwAuwkACQAJAAkACQAJAL4KAAOU/yAcdCLqJABCAAAYATHwADDwAA93ACfI+zD9 aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+g MnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HgIYAAADGAAAFRgAACEYAAAjGAAAJBgAAEEYAABNGAAATxgAAFAYAABnGAAAcxgAAHUYAAB2GAAA jRgAAJkYAACbGAAAnBgAAK4YAAC6GAAAvBgAAL0YAADZGAAA5RgAAOcYAADoGAAAABkAAA0ZAAAP GQAAEBkAADAZAADuAAGdAdgAqwABthvYAKsAAX4F2ACrAAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+ BdgAqwABnQHYAO4AAZ0B2ACrAAG2G9gAqwABfgXYAKsAAZ0B2ADuAAGdAdgAqwABthvYAKsAAX4F 2ACrAAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+BdgAqwABnQHYAO4AAZ0B2ACrAAG2G9gAqwABfgXY AKsAAZ0B2ADuAAGdAdgAqwABthvYAKsAAn4F2ACrAAGdAdgA7gABnQHYAKsAAbYb2AAAAAAAAAAA AEIAABgBMfAAMPAAD3cAJ8j7MP1oAdACOASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4 GiAciB3wHsAhkCRgJzAqAC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAGAEZAbhsALsJAAkACQAJAAkACQC+CgADlP8gHHQi6iQe MBkAAD0ZAAA/GQAAQBkAAF0ZAABeGQAAXxkAAGAZAAB7GQAAhxkAAIkZAACKGQAAoRkAAK0ZAACv GQAAsBkAAMsZAADTGQAA1RkAANYZAADrGQAA8xkAAPUZAAD2GQAAFRoAAB4aAAAgGgAAIRoAAEEa AABJGgAASxoAAL0AAn4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B 2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHY AL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgA vQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAAAAAAAAAAAA EQAAGAEZAbhsALsJAAkACQAJAAkACQC+CgADlP8gHHQi6iQAQgAAGAEx8AAw8AAPdwAnyPsw/WgB 0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoALdAvoDJw NUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB5L GgAATBoAAGIaAABqGgAAbBoAAG0aAACEGgAAjBoAAI4aAACPGgAAqhoAALYaAAC4GgAAuRoAAOMa AADkGgAA5RoAAOYaAAD8GgAAARsAAAMbAAAEGwAAJBsAADAbAAAyGwAAMxsAAEkbAABVGwAAVxsA AFgbAABjGwAA7gABnQHYAKsAAbYb2ACrAAF+BdgAqwABnQHYAO4AAZ0B2ACrAAG2G9gAqwABfgXY AKsAAZ0B2ADuAAGdAdgAqwABthvYAKsAAX4F2ACrAAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+BdgA qwABnQHYAO4AAZ0B2ACrAAG2G9gAqwABfgXYAKsAAZ0B2ADuAAGdAdgAqwABthvYAKsAAX4F2ACr AAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+BdgAqwABnQHYAO4AAZ0B2ACrAAG2G9gAAAAAAAAAAABC AAAYATHwADDwAA93ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBog HIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABEAABgBGQG4bAC7CQAJAAkACQAJAAkAvgoAA5T/IBx0IuokHmMb AABvGwAAcRsAAHIbAACAGwAAgRsAAIIbAACDGwAAnBsAAJ0bAACeGwAAnxsAAKAbAAChGwAAohsA AKMbAADhGwAA4hsAAOMbAADkGwAA/BsAAP0bAAD+GwAA/xsAACAcAAAhHAAAIhwAACMcAABMHAAA TRwAAE4cAAC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgA vQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0AAbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9 AAK2G9gAvQABfgXYAL0AAZ0B2ACrAAGdAdgAvQABthvYAL0AAX4F2AC9AAGdAdgAqwABnQHYAL0A AbYb2AC9AAF+BdgAvQABnQHYAKsAAZ0B2AC9AAG2G9gAvQABfgXYAL0AAZ0B2AAAAAAAAAAAABEA ABgBGQG4bAC7CQAJAAkACQAJAAkAvgoAA5T/IBx0IuokAEIAABgBMfAAMPAAD3cAJ8j7MP1oAdAC OASgBQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAqAC3QL6AycDVA OBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeThwA AE8cAABtHAAAbhwAAG8cAABwHAAAnRwAAJ4cAACfHAAAoBwAAMocAADLHAAAzBwAAM0cAADOHAAA zxwAABYdAAAXHQAAmh0AAO4AAZ0B2ACrAAG2G9gAqwABfgXYAKsAAZ0B2ADuAAGdAdgAqwABthvY AKsAAX4F2ACrAAGdAdgA7gABnQHYAKsAAbYb2ACrAAF+BdgAqwABnQHYAO4AAZ0B2ACpAAHAIdgA qQABwCHYAKkAAcAh2ACpAAHAIdgAqQACwCHYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQgAA GAEx8AAw8AAPdwAnyPsw/WgB0AI4BKAFCAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQGbgaIByI HfAewCGQJGAnMCoALdAvoDJwNUA4EDvgPbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAARAAAYARkBuGwAuwkACQAJAAkACQAJAL4KAAOU/yAcdCLqJBKaHQAA mx0AAGweAABtHgAAbh4AAH0eAACsHgAAvh4AAO4eAAD6HgAAEh8AAEIfAABUHwAAih8AALkfAADT HwAA7h8AABcgAAAsIAAAWyAAAG4gAACCIAAAvgABwCHYALwAA8Ah2AB5AAHAIdgAeQABwCHYAHkA AcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgAB wCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHA IdgAAAAAAAAAAEIAABFoATHwADDwAA93ACfI+zD9aAHQAjgEoAUIB3AI2AlAC6gMEA54D+AQSBKw ExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9sECAQ1BGIEkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEEAADHwADDwAA93ACfI+zD9aAHQAjgE oAUIB3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQ O+A9sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFYIgAACk IAAAtyAAAMwgAADlIAAA/yAAABYhAAAxIQAAbSEAAHshAACOIQAAviEAAPghAAAzIgAAbCIAAHgi AACIIgAAmyIAALEiAADJIgAA3yIAAP8iAAASIwAAJiMAADkjAAB2IwAAiSMAAJkjAACyIwAAvyMA AMwjAADVIwAA6SMAAPojAAAXJAAAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+ AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4A AcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgAB wCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHA IdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAAAAQQAAMfAAMPAAD3cAJ8j7MP1oAdACOASg BQgHcAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAqAC3QL6AycDVAOBA7 4D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiFyQAACgk AAA3JAAAcSQAAHokAACEJAAAkyQAAKMkAACxJAAAwiQAANgkAADnJAAA9iQAAAYlAAAWJQAALyUA AEYlAACCJQAAvyUAANclAADlJQAA/CUAAAomAAAYJgAALiYAAEAmAABbJgAAbyYAAIcmAACgJgAA vSYAANkmAAD/JgAAFScAAE4nAAC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4A AcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgAB wCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHA IdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh 2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAAABBAAAx8AAw8AAPdwAnyPsw/WgB0AI4BKAF CAdwCNgJQAuoDBAOeA/gEEgSsBMYFYAW6BdQGbgaIByIHfAewCGQJGAnMCoALdAvoDJwNUA4EDvg PbBAgENQRiBJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJOJwAAZCcA AHcnAACUJwAAyycAANonAADtJwAA/ScAAA0oAAAdKAAANSgAAD8oAABWKAAAbCgAAIgoAACpKAAA uygAANAoAADeKAAA8CgAAP4oAAAcKQAAOSkAAFApAABnKQAAeSkAAJUpAACtKQAAzSkAAOopAAAF KgAAHCoAADgqAABTKgAAaCoAAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgAB wCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHA IdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh 2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHY AL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AAAAEEAADHwADDwAA93ACfI+zD9aAHQAjgEoAUI B3AI2AlAC6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B7AIZAkYCcwKgAt0C+gMnA1QDgQO+A9 sECAQ1BGIEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAImgqAACHKgAA nioAALQqAADLKgAA3CoAAAYrAAAUKwAAIysAADkrAABXKwAAdCsAAIcrAACkKwAAuCsAAMErAADg KwAABywAAC8sAAA9LAAAViwAAHQsAACXLAAA1SwAAO0sAAAOLQAANy0AAGQtAACOLQAAjy0AAJAt AAC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHY AL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgA vgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYAL4AAcAh2AC+ AAHAIdgAvgABwCHYAL4AAcAh2AC+AAHAIdgAvgABwCHYALwAAcAh2AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQQAAMfAAMPAAD3cAJ8j7MP1oAdACOASgBQgH cAjYCUALqAwQDngP4BBIErATGBWAFugXUBm4GiAciB3wHsAhkCRgJzAqAC3QL6AycDVAOBA74D2w QIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeDgAWAAgAAQBL AA8AAAAAABwAAEDx/wIAHAAGTm9ybWFsAAIAAAAGAF0DAGEJBCwAAUABAAIALAAJSGVhZGluZyAx AAAHAAEACAEV8AAACwBVgV0CAGMcAGscAAAqAAJAAQACACoACUhlYWRpbmcgMgAABwACAAgBFfAA AAoAVYFWgV0CAGMYACYAA0ABAAIAJgAJSGVhZGluZyAzAAAHAAMACAEV8AAABQBVgWMYAAAoAARA AQACACgACUhlYWRpbmcgNAAABwAEAAgBFfAAAAcAVYFWgWMYAAAkAAVAAQACACQACUhlYWRpbmcg NQAABQAFABXwAAAGAF0CAGMWACYABkABAAIAJgAJSGVhZGluZyA2AAAFAAYAFfAAAAgAVoFdAgBj FgAiAAdAAQACACIACUhlYWRpbmcgNwAABQAHABXwAAADAF0CAAAkAAhAAQACACQACUhlYWRpbmcg OAAABQAIABXwAAAFAFaBXQIAACYACUABAAIAJgAJSGVhZGluZyA5AAAFAAkAFfAAAAgAVoFdAgBj EgAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQAAAAAAAAAAAAAAGgAMEABAfIAaAAL TGlzdCBCdWxsZXQAAE0ADwAFAw0LENACEdACFPAAAAAVPAAWPAAMNP8BAAgAAAEAAAABAGgBAAAA AAAAtwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAC9AAQACARoABExpc3QACAAQ ABFoAROY/gAAMgAdQAEAEgEyAA1Gb290bm90ZSBUZXh0AAARABEABQMHARTIAAAAFTwAFjwAAAMA YxIAAC4AHkABACIBLgAPQW5ub3RhdGlvbiBUZXh0AAALABIABQMHARTIAAAAAAMAYxgAACYAH0AB ADIBJgAGSGVhZGVyABIAEwAVAAAWAAAPCAAC4BDAIQECAAAmACBAAQBCASYABkZvb3RlcgASABQA FQAAFgAADwgAAuAQwCEBAgAAGAAoQKIAUQEYAAtMaW5lIE51bWJlcgAAAAAAAAAAkCoAAAYAkC0A AAUA/////wYABCEBAAEAACQqAAIABCQqAAMAACQqAAQABCRaAAUAACCWAAYAAAAAAJUKAABcEQAA gxgAAMkfAAA/JQAAkCoAAAAAEwAAAAEAFgAAAAIAGQAAAAMAFgAAAAQAFwAAAAUAAAAAAAADAACL DQAA2Q8AAPgRAAC8EwAA7hUAAJ8XAACvGQAAcBsAAAUgAACJIwAAWyYAABMrAACaLQAAFwAYABkA GgAbABwAHQAeAB8AIAAhACIAIwAAAwAA/goAAPcLAAATDQAATQ4AALsPAADqEAAAvhEAALASAAC8 EwAAyxQAAAsWAAALFwAAAhgAADAZAABLGgAAYxsAAE4cAACaHQAAgiAAABckAABOJwAAaCoAAJAt AAAkACUAJgAnACgAKQAqACsALAAtAC4ALwAwADEAMgAzADQANQA2ADcAOAA5ADoAQAAHVW5rbm93 bgAADFRvbSBIYXN0aW5ncywADlJvYmVydCBIZXJyaW90AQARUm9iZXJ0IEcuIEhlcnJpb3QCACcA DFRvbSBIYXN0aW5ncxdDOlxIQVNUSU5HU1xJUFAtU1lOLkRPQ/9AUERGV3JpdGVyAEZJTEU6AFBE RldSSVRSAEFjcm9iYXQgUERGV3JpdGVyAAAAAAAAAAAAAAAAAAAACgOJB2QAAAAfBAAAAQABAOoK bwhkAAEAAQAsAQIAAQAsAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBY3JvYmF0 IFBERldyaXRlcgAAAAAAAAAAAAAAAAAAAAoDiQdkAAAAHwQAAAEAAQDqCm8IZAABAAEALAECAAEA LAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4ABAHAYAABwGAAABwAAgACAcBgA AAwAAQBvGAAAQwAVFpABAABUaW1lcyBOZXcgUm9tYW4ADBaQAQIAU3ltYm9sAAsmkAEAAEFyaWFs ABE1kAEAAENvdXJpZXIgTmV3ACIABAABCI0YAADQAgAAaAEAAAAAaHwLpqF8C6agfAumBAA1AAAA mQQAADgaAAAGAA0AAAAEAIMQNwAAAAAAAAAAAAAABgABAAAAAQAAAAAAAAAkA04AAAAiU3Viajog IElQUCBhdHRyaWJ1dGVzIGFuZCBzeW50YXhlcwAAAAxUb20gSGFzdGluZ3MMVG9tIEhhc3Rpbmdz AAAAAAAAAAAAANDPEeChsRrhAAAAAAAAAAAAAAAAAAAAADsAAwD+/wkABgAAAAAAAAAAAAAAAQAA AAEAAAAAAAAAABAAAAIAAAABAAAA/v///wAAAAAAAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8= --=====================_848721017==_ Content-Type: application/pdf; name="IPP-SYN.PDF"; x-mac-type="42494E41"; x-mac-creator="6D646F73" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IPP-SYN.PDF" JVBERi0xLjEgDSXi48/TDQogDTggMCBvYmoNPDwNL0xlbmd0aCA5IDAgUg0vRmlsdGVyIC9MWldE ZWNvZGUgDT4+DXN0cmVhbQ0KgBCKgNHIwEA3GIyFwwHAgEBUIgNg0TEByM4gBovI0GGIwhcNh5mi UOKhjEEGh53EAoKZ1MRqHUOJJQKAgMJ0OhyNJiOp0MpzmxuMggOZ5Nx0MJ4n4ph5qBotGQ0k8kIk rGNMKlOqIgFsdF0giErIxyN5tmMPsogJBhOZ0NJuM5zrFOqFSlFhFAyuYNrddj1gqooIxpNhls5p OBwFtFNwuMhvMd7utTh+BGd7vtewErIk3w0OGI1FpON52ro5HI2yVbu+BGl7g1+r9UlY1zFS2WbF BFMJjNE2nE6nk+ohoMJsNggMRlEFvEBvN3MN5mEB0NHMMxv5BvO9vi5km5holGpFKOY61d22go1V Nke59Y329czXrh1EnPe+/7Fs2OQxDSnIwjkPIQCCKYhiSJL8J0uA5hYEA3DeEAxugnLtQo4w5N6n w5QeEAyjwMYyjgOj0sovAcPm+DKpW/cXxg+4eCmKAgiGIofBdE7WpWHMVvrFoUPutsGouOAwjSOS HP7IjvKAOcSQGzyhjFAoRB0ETJBmikgo6vctvov77IcNwwja5kYq4/0AQFAkDQRBUGSdCEJQpCyy OS30pDHDsPjCoUIjfLUuLwGKrvdMEWLxNNGBBGcaxuH0Mz3PsdPcFswR4FCEy+2MgUWhw6DyODmB jEA3DqNslvxP7wDkocyzPD42jqtqKjKOw0yg6rr1YoUBqGOkJjCMgyUHFDAhiy9EU9MUg0bNLxOi lVYjKFyHNIEA4J0OzPQjMyfv85jjjY7gyjJSysqfTL1hi19mTC2dn1DUbmBlU9U1WttW2Bb9ZQg4 aguaNo4MLM6jjfJQxz+m1iwiMo72PTTQ07eLdWhGMq20sg4DeOb9OsMtVWFXjmCgK4jhA7MlDkMo z11AS3OhiV2vbdVE0+wOMRgLgUYTgQkiCJwghaMLEjet6fKHluXyJAtiVyOefjCM0O5KEGTiPmku vleFFZ1nb911QIQXKuAy4VtC3DMNNzi4pk/jyt0z2uEGg6GEA1jLEigZDrdCxVr2cxdsL76ZmECX Sul2S7H3BWdUHC7tgmDDLhEPQphliKHbY0264mejqNwW8Otu0bcFO/sCGQYYrr/Cck7rrJsog6wC MIxMKEAyZg73bDmND9W2Mu2DxCA5jq3ybKAFo8ecFvVJWGVD5vZt5cjwo7uvloQecPDm77XsK4Ju N/OZlo06bDtzhB2Tf7uIPFXXQnVr1x/r7A6t6hAGd8VUmpfav1XvmQ+wFhgaXKMicssJhTmmHLTe iXlZb1WLJjcktUoDGnkBiDagEtxcHaOlZiGk6Ctw4h1J+HR3aSQyp8DYgVYUESouucGkJyTdmhBB TohNrJz0lPwaK0dpL7IRJuagrpn7LVcsQhkbZ+7F4btjZbCeFi6IZM2KczhyD+XChJgSweBhQGFh uYa5xbi3nQujhE6cMjb4CQya7BR18NnYoBN+eJ5Dt3cnMd4W13yungwgeG8V47yY7vMe89BS7jC8 AycDHKGsN32vbOY958DV3xpHDcgVaqt30swjY+2O0OGhvyUw/R6TjpIRbdgqJUj/FtJISUmoOgd0 JyuOY/1yy+YMFESihtpRykrJYlNIwyzrYnwWYWq8t5x0Xn9IMC5a8ZGWvDSgUd9hbE3oJQW7xl4d C5SLlQCgGb1IsvWihD53iZTkzPBAqaaSEVbzWgXNkoCB5uQrm/OFdUp1kErBm/aVb+HYMJnXM5I6 SZaS2nVM0NiT5fpTmECBK6WZxT/nJBOc8FV5nKDedoMrDJ3LCb0G484IA8k/QgHlCBOYUIQZ/CpV qgU6IQDMcdKFMElBmmLOMGa76BzpPAT4F7c00KrqGGWosCDmHOB/U9lTCQ2k3giDOJ1QYLB1DlO1 NJ/Qqhuc82gOczgpE/DfVpEYIAmGQJuwmqsWAGxaoJHQyBPoVJNhAf1AabENpuQAmVN1dQyzgqrH Gjcc0hn5hA6JALzKGzsqidsO77GNS4BAveXaqrGWEoupoGcjynToPWDOVVh4ahIdPJdkIIA6hwqS UMNjMDnnUJufk4a4QzFkVUG2TgbyfFAfc7s8J4yjlJJ+eizp6waTIXVaJIINJzANCKQMHBUgZA3B sC4GhDSPA3Xvd1e73CRXVsvdi7V3AXXeJPem8J2AG3VvZeW7N23+A2BobO8Ct2VANBoDQHILgar3 uvfO9F6r83iv4DUjxW8B3nBADgjxdr44IBqlsF19r5YOvzge92FQYguBmDbDN9MLYGwnh0GxCiGY jwLd/E9+wa4pI/iy9eJr1YIvIDIGwNcL4tnemLBF/b/4BsvjvHuNV7n1wphbDGOseA2x9krFGKiG 5OyPfnKV+y/g5vQDjLl68vENIsRi+F6srZQvrfchuWSRECAau662UMAYiMqSMimYwGgoCCcEnZPT mLVL3dPN5UyDZ4wgV/KuRs0ZYyBe7LeXcv6PIqRfBOC845PIbocqWbAG5uBoDXHmRMdA4zmVTOxU 88AoMYeXQJA1TZ30pocHGidMZIx+bPBGktdFfy/njD2IMRZnIbiXJOjb95uwrfPIupMY6mIpoXSm qgXht1boPWGZC/60yvfHTmz9J5kzjfc1OtsOX7zLgK+wLtx4hzVrbIN/sAbo3FiLDeLyRaf0tkXe eD8I7uw7kzcO6t6Xx3KSLX+Id9cCf5vXG+U8Z4633wy9u5rrA1vuDHgd6tOZC3jZfiwLuMa205hU j2TeP8h0Zrjh2KwZcn4zsXlWxyBkF48DchZUs6goCUG8MSBs+W3n4U7QWr9Uax2zx7i/L9b5ivdr LKvLuRbGvH0flvSeo8xJFt7Q3FQZ3awljbid4775mwr17NN+N7X83hqLst/dydp3wC7BnbSpaa39 jDgHHuu9u4lfrg05dgd67NsTu/BsZcs7p2/hvFLLg0IVhjlPTL98c1F47C/X+YeS7/yW63lvIbc6 kA3GOVPG+P8x0vv2ndXY68bqFe/Oed89CSG5ldU2ZWQz3bbPxQGepQhUxoMdsYFtv2r0TaG2NEel 8v1fzV7+qee9Ppzp3yvP8a9D1rWPncPg5xd2D1O5/G/bXvuztHi979rwFdDdX3f2ep7jgz9X3N+X a8L6LvJUfxeK7D/bD/CP8P1uFuCO0vRuHv4v2uCr3rrPACEvmP3P0LLwFv2uRv7wIwGsKPDsqwKv IvUs3M4QIOcCIM8g1OeAWmEpPkyoGAQGenNCejrijg0mFpglug2IUPiD3OhtCNvvnPkgZQNPQOsP VMEvXQPtnQctUq8AzviwjOjQeQfPrQgNkMQv6QewQCIvsCMNVQlNrwdtZwIMPwGQNtcwltwQIN+u +scOxsBMLCpPyMfN3shw1QzQBPzNKu5QFN+u7QEOSPlwew5PvMlv+tgw1wAw/uVwMw/P2w0LLgYr /ulONwHnpxGwLN/vORFxJQwxDRLMLxJuZM3u3AZRQMHOcwRgxAWtAQbtXQxwuMqxGRNxMROtPwhx QCFL6M6wrs8wkQtOivkQuxIxXQfvmwotlRZxRQQxbwsxUNrRdxVxNRHPrxVMcgYtSQuwzumw0xFx ptht0w3L3PKMBRpPkxqvJsFQ7RsPkw8wBv7xwRqQ5v9uDtgx1thxxPDPSHpxsv9PvrrCGMZxXvzw 4LLx9sVx+v7RKnWNSSBRgPUwCOWSAsovQs3OaHpiPNxs6vjQdI6C9xpKMD7yMruILSOqMRSQSidG XwUDvAWg0GPETRkyIllOQMkgbsJL6McOqSGxOOpweSbSBvpyDR+SEwxQtscgYObOER5wEr4nWSiM RQ2v6xvSASlR8MgxyMGShvAx0Q6Q9smyqyix2yFPAP/StylyjSFsqywyoxrJ3jUtSyBynRGLstmy BystNy1S4SfxMy3S1y7ROiEsRRGL/u3PYOeG7PaKpCboSPcOfvdwVNVLBqJgoEGkOwbF1QcSgujy 8S6wnvmvpzLxnQgTNy6TOvmxbryRGMeLySjPwTSivw2RtymwHzVTTyuypN8zYO6xESvRKzayzu8R Ay0zTQ2SxwMTfTVzduxJ3gcMeAYPovQy2zkObybyCPlxpTkzlwgSyTjzqToQOu3RpObP5RRwSD5l NA0gyIFg0m2G0RdPjxmTpznyBtPNQOOzuwARbRVAURTzJxUzKvkz2zlTtCBtkv6T5zvxjT7OgrpT 9RlzNznT/SBzRtNr4KAziyjuNUIvxzWwETmr70JSjP30IUNl7yrx3O8xpUQUJx3zj0TPCQ9ThUSs QQDu0zSAbuusiS2TX0ZuOy40SUcUay9R6MZgY0eQJSHtXTuLzQqwRQSTyTzT0A5QSnRqzg6A4Ceg Wzylcq0nQkoEqECg3lSJgGEzJOhUEz1zN0hT/whT5Ujwiwtz7lwT1QdUy0aUhwoUAQpNN01T602U DzKUFTLUzUHRoU7iFMfQETUrvDZymUM0b1B0J0PJ31DtMzbslzc1IUTyvy+1K0VwB0W1KzUNNsUz oS21QUdTc1R0fPRUW1TTMwOPVy+xtjAM8zHohklApgyjCk+TDufPdLfzFvfKJvgm2ij0w0ERlUyT LVVPMvv1j05zNVlzoUHp3gbMPpHUJzU1pO5RtN21FR/uMVp1CO4Sp1P1vP5vT1JzpVr1qSx1L1o1 x1NSsVU1x1PJ3xyL6UbVuV6SHTrUSV8ToTrjQsI18xg0itNuyuEOcnOpsUnFqnSAyoToUlz03tDT LV+T3iBxYz5WCs6UC02T8UxVi04WJ2AUz0A2COu2DWNxlxkT82P2JT+WKVT1oF3L/rsVqxr2ZL0y l0MO4TXt4WaUO1wp32esRURTcTpWhVLTe2b2aV3R3UW2j15FlNSNx17T5LPuFVSTpWrWp1T1/WtT Q1WCCCOP1LySKz7SOD3SNFNWzl1W0yP20SPEg0o0pg6UqlcQYAy2GWHHTFjSWWxS5sXSZumzLWvT oTN3CSd3B2pWvygUFNN2rDWTZRrNuXHzWVtWd1uXKVG2gWoxy2iVzMMXOXIRCzePA3QzgXIsYUW3 M2oLruzWqMiCEubO+WuUSXW3Z1VwLvSXY3XVTwOvWFlCPUJTAuegpikA6Fa1dDhTFPezGmNVZWE1 h0+VjT+XbTq1m3qXZXrVlXsXeXcNHVAp3sdSu1C2bXxL1VE3Lz5XzUYQ6VHS+L43PRKTpX12kXS3 6WmSFUW36WoDQwAXXsk3+v5WsXQYA1mX83dYC0zwPFDRptTAUAxqtGWijgWyRF9ifWIwmQulDMeY BXe2LT43YR1012UrLFTLM4MReM14E2Kv7NlYGH8NTz12VWPSLWW4NYV2YXwYNu5WatuX+0L3LX2z X4f3NTaYiX4u8Tc4iV1Wk4iX8Xc0gYl3UTjCOr73tQ3z5TlP6YBtN4tYry74vYFTuSq1qWDzIG0G ig5mPgzjoihgQAtmyrBguRZigG9ESDmq7oEGCjmAu4UT2Yw4WWL3YYyVYRj2O1iYa4Ms15AYPYW0 BZCYR4ZU90x2QT+ZGXvMtYdAYOutF4p0KNi5OVsvyv9y25Ntt3Rt73N5TM0YkPNzpZV1vysV1iO5 QxCRE4wZa15PuRw1TynZdx2ZMZXMMZf2A4DsZ5iYxCpAcseWaOcoNoO41TDgWqjY/Pp5kZA4QF75 l2cZIyLqkqlkz5quj5r5G2SAQZt5m2UZJZxPk5yZg4Y04ZlCFOUZPPwZduQ30YhR/57ulUM2gZ+V yP6y5Zz555+x0ze6AYnxM6AV5AcTeydzbPl6GxK1PX4RK585SQH6HPA3/v5vq5bxxt8tDsMZWzo6 SaH3aRK6RvTw9V16V5baBThaNyuZ3zr6XzgvSab5PTtu6r7itzwRSlZKxgz28LciymigyIOqwEiK 2g5Z2Qu6Z3Fr3T4Qhr4af51SLxcxk5E4UsH6UZ3xhP6arUkRj5J2WZFavaOVTiAgDWVuZHN0cmVh bQ1lbmRvYmoNOSAwIG9iag00NDE5DWVuZG9iag00IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJl bnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDT4+DS9Qcm9jU2V0IDIg MCBSDT4+DS9Db250ZW50cyA4IDAgUg0+Pg1lbmRvYmoNMTEgMCBvYmoNPDwNL0xlbmd0aCAxMiAw IFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMBBAoEcjOIAaOBoIBuMRyLhkOIGLh uMonFRAcjKIDNCYXDYfEYvFhhFItGo5HpNDIdEIkMxsNBdEpLGJRHRoNIeNYtIJdI6BNwaNBrJRl H5bIhxJYXNZPG46NRnJZjLJDNJXTozUAbUhiLphVp/U6zK6ENRsMhcMIlPpFWq1Z7Ta7bSaxGLjX IVDLYLhpd4sMZLEqFOZ3Pb7f6BgpnW5TUqpH8TgBBjMJXLRarZfBxfsplsdHcGOawONJE9NhIPKo wN8mIJhMoloKEQioDRjOZZX7CICoRAbBIHGdWLyNAsZm99ohBvjHw98dxAKCCdDocjSYjqdI2bjC bTKKd8agaRduMeHBdXXhcMcRncVWtpXNHpdP9eJCKJRsl8Ikpa/MqwbQga2yhhqGoXJ43awBs5rf uC9L8gaFA5jyNw6DCPDxCo8jzNxCSDIQ9j3M4zzFwGoT8RWmbTxEroZt5BzXP82D5RSrkDKkG0Ao bGUHuA4T1IRCoXjbDkPPPEL1xi9r3xPG7GxVJaEL21wbopBy4LMvSZNaGEsBvBzYsavKUsNBTETD LSypsrj9ogyU1hBACmy4x6yKrK8sqBMyoyasM9zFG02qex65s3QU2LxO6Or2Gwcx5SMUSlN6dTSE FIUlRbAxxPDI0zSIXUnKLL0OzSJU1UdOQFSqUwM3KF0gh69t84AUDGN42jgNgyjoNI3jcFtfvBJD yyU4UXxIi1VVIlb51e26iQTBdZpmhdbQjZLVhQMgwu4F9iPC8djxBbcRybEtm1ZaCOx0mEA2tWsI SFCcK2ND70XPGCv3VUVnIxdttOHF9H1Eo8+0a1lmYOhcyMowtL2rhuEzdM6izjUMeYROqgsxPNZY pLeLT/H9VYQslGZIrtEVTkVCwJR4cQS3VSwJNFq5mv07YDT0/1AG2dZrZ+fZZVFM6FnlO1ddzzt1 oLOhmi1shQNQ3jEFo5wy7gWo0MI52COd8WRgkmX7Zmk0pU2mwPam0ajqd6SpCg6DyOCNosMo3DrI 9yXzudl6RmmlVbtcCtvHd4hxuEgYHIcKb7Dty31st0bPwWd7VAl64LWSFZhP2F6RLyLYfj0z4ltH SYrQycYxhGg9XjvQsgFyq9j0GFPYsPcIxlKSd1lvR9zldHhuGdR+BnumKH1NM+P5PNLPkHn+QHPl aXwzMrp6vo5s2unVlMTG6oNNdo0OY52ANw5hbXNd167gybHc3K35J3u+v6Uc2lBFMA2fGRJbLnFu BjDCHIMgaTvBsfo5Rx7gYAPWew4VAi70ePiR5AJuS+17t+bJA9dKzHoP6e+fRubxnkQTdC58jEES IGwJimVhTOIRQpdYzd174obOzd09SF0Koesmeg6VkbrWjPch/DcoSjy5uEYFDRTMTX9qfdsrKKUJ VTxIiu0R5isGng2QSSJqh4IEhhayGgMqvn2vvV4r4Mr84PP1hA5cG0W3luGQMtN/8YCfwDbmriA8 CYFwNcBCGKJaonNFgsvGPkYoNv2g65Jv6+4IR2ey5uE8VivtBiUl0lcdZNkvhixBSxh4oyhk6xc/ kp3bH/KY6dn8VZWSciKgR3aDpQStUIyqIz2zNy5lozCJasmMOLimTh50YDBmfaK7V28xZmPMl8qm aEx3Dm4BlLgqSfGqBKauCAOcaFfHNOqdc7J2wyhzBAFxCs4wxB5BAGMNgaW9B0C4CmQklJDTKJnN F7U+5qxYZK/ifkxqBOOQmo9jAMVWQrdXPyhkMDZSwebKaiFDYZw5UzQtB0PGVzOmISWiMtXpsmo5 LuCZcmj0XlSo5WQMyHlhoPFAG1MEGzWpApmm1MouPaeFTWmK7JFPhUyDQtTCGqNWaxOGNIdGxRxg chOCFO6hRdf626otR1sSPceChurdzYAgb03yfL9qp1BmtItWVRmMx+g5U+SUH6pT7qpNaAiVaXmd KrSST0LQZ16YdKOilNK/yyr5KpjNNbAJ0le7SH1ha9zCY+yayDDrDlRp/ZWlpHlMgySwXumcybPL XpxD60doKey2p/aeRNVpsS4d+40FE3gxAgCKHaeoIAkBhDcGSeYbiDzlOwdo7k6p2BzndPCeU9EM T3rLHOglrLSx0ulQeCF1bUpTX2o+0aJbLuiLSlhErpnQ00u7EBlacHYXnsYgGxzQL2XflvZ28URL JRZl/fG+9LlMgwqwVoGUm2bzJv8pjAGAnptAwKgvA7trVUrwXBPAODnwG4aeUm2Qbg3q/DMGmAyv 1ggtWMDcmiQDKx/DLbhDFcDyUyxMCgOAcg34dV6/QGQNVU4TLDUYiZisKlTIEDbDFbpITrq8HcN8 8Q2NfuROrGdYsVVOBZc9CYMsrKZoYWB0qbMfWToJllqVaTbg5yCYlxtd0KBkDLPO3Acg85UWVPvC OYm2v/yHVxe1X28Vib25FJMcq5x0zBBNgVassEhzPH/Pzk5C6CR5mGg+aFHgwond+FizNKGNvJDP Amlb9oHlWDbTMrr3Q9wVp6XktlAS41HSiik07+6opSl0EGOIbYNQcxGU2toX641UqDXmEsEGYeFs EoGE9cv8AbmTWqopjLZqii8FBzQQLGBjiVWx09qbW2wb/bRzduHQ28CjDWHMPLffWC0MIZAyPoyb tbSGJs0bTnYeAOgaA3hkydvcMocgQb3t5WINoYQ0wMqg3PZgNQckL2vlyf7l+FWtjxmMgWOEeHKz xtKA5Gwwggxi1dXobQQB3DTvcEECjuByDcr653B59cQBxre7Oyo9IL4VBmDSQY/taOxcDODZn8cR zo4khfN5+6Jg5ouSdZpDdC0jJnWoOJEGUocSvHHU6JQyvS87q6UNP3q6L1JE9HpevU66fHT98+zk vvlsXsXaNUzD1rqLo+vtdKYLRMvY+w4qFV7z3UleyMHvc7/QbwPfG2HuQcDUG5Mi0WytoCAKYY40 BkDrb8g4SX2HXDqGPED7AQXCnPcXI1yA6AgnesYFpYQWmg2yriec9eW1x0BnHiHdPDR31VxAhsur rdN97MH3V2n7F77/SPT+l+50iTHYK8vXO6fI7im+jXx6O2N1NLL61m+1fRTH21o/29LdFUvTz4cp e8flqrP/YH6qcbF/dQeL3RSeVtQg1Vq4Ld8Bsjh7TaLoBEoGr+LmZaLOrmz+qpDjJbgMQN4N5Xq3 jn5yzoMAb88ArojWsBCrbnSt8CJ+8AMCiS74hx74wv6wz5J1cASxbTbrbXcEqyL6axBhEFKWTsjX 77UFxwixxH8GYqq2J2j+Cxb8bWoGaz7iTAbXcIi0j37YEJK1ECqzD8MJsIzCpWLWoGgrSpL/LGJY A7BusDpwIqUIrOjmoi0AULEBRIjPQEBvLPsL7psKToZeD8kM8DaSDFjRjl7oMODp67bosJK70E7q 0P7LbWUI7vEQazbsEIa+q9pwjBL7URC+TVcRZ/EHx4MKMRkIQnjR7QhoqKETbLS0rYCbMUK6zYsU jSEAjxI3QnjRDaCP6pQFsLZDDdQMzlKBsVkVAizZgpjh7oMXUMZ/zmwGUV0NDNJb4MpcJ8xcb/zR sX8TkOKC7WsYiF7IirsO7pa6EAMYEPj4rorG7Bz8bq0cD5sQru8YZBKjC9L6sckRrV7s0dsSUHcd sSyj8U8dKzb4w3LrUEL9Dm0faf0Gzv0gD978Mgj+SogGoGJLCTibsLTnoOgFrGYM0WQMoMINcNzi Eg8VSa8MjWshaXUazPJuwjYGbPisjlzpkjUQrQpxEOUj8hjnKhDaUbCuT2zoMjcJ8mY1cfQmQzcc QjEhUnyUUc0f0Msfcn7r76spDUkRxj7YEpj7kScoR7keqXrYsqMTQGCFMgMc8MsrYn8Jb7UsAt8j jWAosrjOkKoopHiiMLJrAjQ7hDDdJu47DfMjLoMskrrmkYUr8tpB0kTaSAyBCBQMLg0ZsPMAMvUa JAMtg9swEYySLP7/8CUxUtMbsEbooGAtTx8oEr8zkcsfkQzm0zZBUdSI0RQos0Edy98sc1ceSm81 U0zV0H78M0szsE4EAnQr5Qa0KU03ZPksQqs4E3ssx4U4j9aCo84zYnQmQqpqgIgN4MZvi3IIidIM Y7AODz70I6y4adEvBEs5C6Z/E8T35y88sjjSQhc4DSkfJ1c9iwMop1E34HIr89q78RU+E1j7M4c+ otcHKIKm8/Uqzwc5k/0+83Iv6Vc3xTFBRjM4U9ZABhEUxo9B1Ccjj+c3TmJ/BqgMk6U6kWgMwN4O TgYOk8Ai1C0KcvirAv55BEswJbkNUNklExElU8lCVFUC0l9FtDkyMmr2sAFFFHCuzqAGgG6U0z03 VI5TEFc1B51I1JEpSVdKBTEGsR84dJbBjtMSdKhBdAilR7lLq9CIwvYohLCEjw7Cko03Txh71NLZ Lvs9dNtNAjDwVME5lObYVNUAowQiVIzAU6FD48BDAEAKDGTyzzx9YEDzTnjzs7b0S4idL0q5L1Ta 4ED1pAb165b2SfElMbVFFPM8c8JoJmBgRwIGlUjVJgU9VNhLFMZmM99NsQk0Ur1VrXtKRjNMyF9K 0p6WVXVV6ktAVWU2kS9MNYcIQnMaVBhBdZLUsnSnNZtHMKFMNVFZ0ftPg3RNCRxW9D06dQciNEVE hb9E83VataUjsvtcoq7pCSFGUk7pUm1INctZVDEl0aVbUmTedH8ykD1FFc1IkPtcsdLqhhT5QnNg brKUk+dBooj31XBhFg6XVXlONgVh0GCgbHdhqTlL7YlCtjVgh4s9YGY2UvdhdZlkbwFZ56gGllD3 Na9ac5lltksVdkROaMaN4NJvhrLNYMrz1clllkkYNFkJJQdGENMkkNdd9n9mUxlmqblH1pdoMzCh NkQmT6TWYlNg1lCiNJs0dFFrc06HFKdsE/aj9ldsk2DHdslji/FP1tFBIGR5D81l6itBtuKm9CE3 Vu9uaClO9P1vc5MKlbMUkBJW7PoMTfoFoOoOFn9wFoVuxjcDUndo6sFGdeFIEytFFx0hBGFe9wly VfVxtuVwKE1gKowtUF9rClwld06WVrtWt1t1KwajV2IhdiaWM4bK0E1i5+7Hd3UHr8FMN39AFkM3 QGIr8J1uiKAGl48JUs1ld5t5NvtjtMN6Nc9DN5h1ZqjDoNwNKcKBQM9n961x9ZkfYjFoxulpFy18 V5F69exAN7Ild9EyUPFG08N8dqZzt4xy9JN5hy919Nd/x/E/F2l5pEt25GBUGAUQF3i+eBa+2Bs4 +A1YDWkK4ksVMnV5YGGC8TqaVleDcUs41CuEGDFul7Esi2R9TNVfcZ08OEmDricA1FGFF+ddysdy 9flU+F9ps3WGlqFTzQM8mHd/MnhhwHIh9sKYYlamGJFhKwZ52JkcNh+I2JuBCnOKOJLLwsOLFYke xo+LkISv4ztmdutLxxc0VUx6mMWNCZp4WNeMlDKmCVBqhXIOCemFkxJ0uM+OCq9Jk/0hsyNEaQUw 1cmN+HmOUkOH9GtT42GPdgEb2RozspN3j5WNYzeAFk2PWSVkE1CjWS0psd5UGT8qRH+UdtlmAl+M +Sd1SzgmCC4ylO1NeVzr1OrxGBN1yOuWgi2WNtqGGV7vdPdmmRr5i2UWblJrqdMBw7bdK5BXtn2I Em68YG9V2PmGWYcx9diruQUwsw48ggVTB8jcYODggOWQuXLuGE195hxAEt2RUyeFp0uacsM9LqAm BBM4uSh1eexPmTCZCU2fefGVkRWgD69a0gSwOe+LJPGUqPhQeU6I+S+huhS/gGcARVaayKGiomRg FumK+i2jl6eXujWi9zkKuisMRqmYwFoOIOswzkrN+aFeWkekElua2k60mGt9VpWmNzI2Gj90lHUa Wm5ecOsa+Qun+R8zOnwmVC+fOJeixlD5zTmf+qF4mTqVekZjj7Fs2UWquUim+rKyztON2r2MJqV3 eXeW2jOs92WXl3Bh2thwmt2iAl+uOYFOGYVkcaGlIMIM4MtneZ1E2nlfo2FlhzNzkj2vUUN+ebaQ Zcmb712cWcmQuu1zkC+xTMN+ePF+x0uwxocnVVgGZJtOmVmSu0dWdhWf1Jm08ROT21mK2NW1ltJM e1mh7WG0Qr+0iigvZGODmu9rw2AxmEsNeW2K+4VPWvGum4O3zuzZTxQ2FwpClSCdCdVcIEAIZYLN p9RYIEDJ4KgMoPD04IzgtSS49Shcj1ZB2cDnI6dTa5tTuReIK8e49UR0rCeBmjqQxqV/melgIqeJ tJO/7B2fuMqInAGKZG2KurbsuUQGHA+BsSfAT7+seL/B2KWfMNY0mNh5iKEYmMcUSWXD3Danxo/E WaukwGGOb+7kjawkjF4Mje9cnE18iInFWope2xuQmwZwPGey0l4qfG1yZCmzeRnHu/uSHEWVe3Z1 fJMolWlNfJu1qVfKO2BUHKO2fDOTeLsq/EvDXJSh0NYHGamjB5wiPMdvPM2edZ54XNMssnVDMYmY hqhXq4HGPHaQ3Nuasj3OObGxkwmx2+OaOXfMXNWdNzpAPPmdvG8mnGXQnN1ulVgiJHk3Gp1OoHHS c0O1PAvMPTHKRjPSU2fKvEPS82fLHUDx+23NnUnSm0ohaz2hPMiU3V84N5/KwG/WFCh7nWegOkOY SzyxfOYMsWwFrgYgyBXGXW/WnN+PpBfX6WV+cweQebt+vIvZPXmmsC/Z05+d3am+WXfa2oA5lgPW dBHSvb5BM9vAnDvZPcugSjXcl23Beg8Nfdmqz3am/eHLdAoiXfMISbOplc/DqGOpu/PK3gdc7WHf 9B9erC3VyAFHpW47AM4NEiPYoM/Y/O5y/hXgnXtdCrCbMRnaCQObnGXg+HnkHiHIV+kbPb0Nfk2I ivHlx5FLXc3mVJmqUFhTCbPmeCkGPh3nlsvBnEKmrA1LZH/ndJl4IzfpHmnVsNb+tVUT3MvqGGHe bG4tXqKaXNnqktQ3TG8fBqgOgN4OHYiA/i4N3GXrmxFdPr7B3kXP/HXQNeXq9UqofQ/Vx/0yHRZb nInlvunrJw3SPpvJbwNL3nFJ3WXwa8vd5BfUQqvq+r4sPyHVPEvxVgvV15lW+DPMvzPqtK/zAr/z 16npfzvrvzEoa2UBg6xXXsvY3tHjJ/Ao/0PGkNYnJ7nt/aXGX0vH0aQo/1GzX3X2fmCzgo8Xs9zw MK5E/dXzn42AnKf5IxXx3zH5vo3fH6DtnCnXX6890Ncaj4V5XMv72MinLK2JH8fNn8X00Nes7x5q gjRu8ZAMhYYMKpfsQOHvvQX7v832luM1fPwMggBpNxhNgpEBUNQNIpUBoxEAwh4gORnEANGozGIu GIyEAyGQ5Fw2HEPFw3jgxGAukZyMogMwNIUMi42Fw0jozGQuGo2EEHIgNiFBiUUBooOcGhEKhkOo UTisXjMbjsfkMjlMmEEolUSlsvoUQpwNHE2jw4Fw5nlXjlqrkusQ0kscstnngzG1wq1xtsvGg0kA 1uQys1oklYtkstw0GspGVkwV0EA4lM2w9diwzlN3qeDtN6ytuqAuu2byGYz16xEvnc5GEjueEtmf l9jjoxswxztYrUry19v9y20a3MnlO80GmzQy4O4wvErepiw21mu5fDrPFvcwpd9qcZGE2n1FNBlM JkMpyFp0Mp4OlIhMLhsRsFE0NS5W36277MxBuKGqdMC7zwCon6vqGiqjDoOSBDO9ylPipr6IwjTg Pw5rrueyz+Jmmruhc76ewIoD5QOoqjoO96lxIsL6wq4ULv06EDLC2jlBumrKNOrDoLGvUbRwEC7L xC7oN9ADaxu7jYtQ3rFhcxskSAyUOtky7MrIGMkxyw0mOOjLRx+7jTS5HbLNXD7qS1C8qxqGCaM0 tkYt6v0jhlNyQy25zjNU5CyTvOC9Tk0DpTQjs/zzDE9u0hruTs38Qp+FAzDeN71PQ9T2Qc+CmIjF kJvtQ8YOw6D+P9OoYUe8MZqJBMFjdBsUQfTj5qfT65VDONRw0mS7Q7R0j1VFdWROpNN2FWqo1vN9 EUEr1jrfQz/hytcdI5Hi4KxO1pI5IStyrIzAWis9qTJa0msZP1tsiyciTNPtxWnNcuz5L6eW1ccg yXMtBuneFyX+7LaBiHL/qlXMMsTOlw4HguAWbK08KzgkKVFhDVUI1uJYbitFP4GLuYGkbwhQNw6j aMTzhaOAwjOMtiRTCFOwlZONYpg+OoZU2FhzkURVXBAxUoNjyDdTUVQjZGKYZm1A10t0N16m2Q0h EekRNo2Y1oy+aaXg2m4tquZIrgQcrhRE2Wwk+yw7bq832vmFbVs15be/snShge5ynRDoIvK+Jbnf VzS80SebztnBOzM+M8Ps952g2wZpDjjs3Ak4cck/OnT5v/I8nm/FYwkfPc1sGPZAHCaBpntIvMMw wjqNg6BbSY3PbWNjatFqs8xz+v5xuz/4X1Ka9ZsOtVbBmsVnEvd9JylSV51XedV42f6v3Gj7Frel d70tFevgQcJyHG3YBa9A/GlSR7bduE0e23yfN9y+bvqX1fLdcqcfv2I/i+tujg16OFd4/JfK1XQr 9f+/lxK1yskmUK6BIrcYHr9gku5zsEGMwXX4oVLMFnfn7O21IG5cDCMjdc7B2QLQxhoDCHIMIY1L AtDmGV26xXtNaedBp+bD1Sg1eESeEpkFgtWBQHQPIcCWkcDKyUNry1nw7hAbpzai0OQkhMTyIr2y jRQd0raCsEYQoyWewIG69YAsBbTA+ND7VvwUSzGiBq50nwkjQ3t+jEDNRxgJHNwho4+GjTG+dMzo o2R9gRA43BKSdvQTm/AG0jHvuKXfIsnUk2+yGktI2DhL3TtSBs5I7jIwxhvdtE12Yb0FyoDCHQNM povPbedJGS8jnCFSk3JhXZl3pm4lEgNAqz4uvZay82MEuZbLOaswIGpIDaR+NnGsGMzSVE2jc49y xWZqTPkTHRvE2ybR4Sq/2Pc4I0t9QnICc0g48uLdHOaaDkAZlmSgWw5Tk4JvwnnHVC89yeToc7Pu eqPiMz/kLAqgSiJ/QiIaDJwwNSMrxZGEoN4YgQBSZcG8OocgxktBAEEOiCg0hiDqeoOYIAuFGhsC AMQeQQBwDkG+joc6Th3DQGmFqDgWmjBafonwIAUUwDeGQOtMwQBQCIEwlwaWhg7JdKoEAdYaggIE CAOcLQy1EDYgwLgKZYw6mPQmZL3JcJ0RBJ2shJ6zLMiq+FqQM0brhnij03VcEjzXbrNkGNdq5TdM S/YrNfCOTif5JWwU513Ror3XFbk8Z3WBsZYgtzAqHQIYfXqyq5VEyUc7Zlh0VbHkbJpZqH0IyslU i0iIFAZKZMmlQ7SVQbZWoOByUKn7zCwzDKSWlSCJHkAtqlVmr6JQZAzalZ4EBnXVyUa5citEP4g2 nJBamYMRokRKI6CCJrJrhqeubaOz7pnpIdI3dNqgKInzEivae8FySSXLnRd+y1bYy3HOs2hQNDkg l3W9NiOF+p4mKXRex/TfIMP+wBX6AcgL9TsnHJrBNmpFTTSfWOvWFLwqKnI1LDFY7Q4dufaYGJwW MsjdqHQOdwIahku6zNpWIIxy7Z0SfEj1phBzpEq/FrSZcYwipeKXl5MatUevejHdaSs4+T0dmt2S WzPzvwbpj7xb9pDje/DKdy8A2AxHk/As7ZK5ZyhYWxWYoD4SoPB7M1c2pAwczD2Ktes3FVw9JXOZ IsPSazvnDIDH82k0kbKRB1vKfgohdDCGTKYa4oxVcKYluMXS4z3WO6CRyUaAuo8dEsR4kxLu1E7I 7ztJ4hyDn+WsW3kXphxMW7zStR4xLdk0lBOTYYKLe03Whdb+PznzpYGGubJP1wHrMyFhG64bOvsC x06XDa/NLY7PWytbG0Wmi+tE2dqnMrRsjbMuoOsZ27pS0zE0QMjDbVkNIYdG4s0fFGMG4dSYzBBu SYGmrc3X09dvVTMNIY8I5vDWEnrxk23pkSYW+1ZbuZpwDH74L67zIykracawc8RmtruPO2OLbBbt gPiqUl2TjXfx/iWaI/k85JNbaC/eU8cNolNQHDY1AgBuSBeObOac2YBlEjnNV8V4gEf2CnMK2Ngm zz7m+tsBT86RYPkNhW/9Ezq3/pvHDQmj6rg5/khupbbkN1Xlahewa2k+ZFyS4WRhzDSebFNwd2ar 37kjrvAVF7yd72hn0wt8XZ31qGMHc+ZPR1L2ZYHeYjMv4TF9mngMlnQICA1lbmRzdHJlYW0NZW5k b2JqDTEyIDAgb2JqDTc1OTANZW5kb2JqDTEwIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQg NSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBS DT4+DS9Db250ZW50cyAxMSAwIFINPj4NZW5kb2JqDTE0IDAgb2JqDTw8DS9MZW5ndGggMTUgMCBS DS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqADAQQKBHIziAGjgaCAbjEci4ZDiBi4bjK JxUQHIyiAzQmFw2HxGLxYYRSLRqOR6TQyHRCJDMbDQXRKSxiUR0aDSHjWLSCXSOgTcGjQayUZR+W yIcSWFzWTxuOjUZyWYyyQzSV06M1AG1IYi6YVaf1OsyuhDUbDIXDCJT6RVqtWe02u20msRi41yFQ y2C4aXeLDGSxKhTmdz2+3+gYKZ1uU1KqR/E4AQYzCVy0Wq2XwcX7KZbHR3BjmsDjSRPTYSDyqMDf JiCYTKJaChEIqA0YzmWV+wiAqEQGwSBxnVi8jQLGZvfaIQb4x8PfHcQCggnQ6HI0mI6nSNm4wm0y infGoGkXbjHhwXV0uZ23X1raVzR6XT/PiQiiUbJZ3FeyFvilLbKGGoahcnjdrAGzmt+4L0vuBoUD mPI3DoMI8PEKjyPM3EHIMhD2Bw9z+M+wbQuCmb6xQ+jVIQr0Es4zzYPhEratuqQbL9BDewY4T1IR CIXjbDENPPDr1sHEUYxmxqhR7B69tcG6KQUuCzL0mTWhhKQbwU2LGrylLDQMxEtyosqbK4/KIMlM oQP8oLMLIqsoymoEwKiGbeQVOkuRlM6nseubNz5My8SslK9hsHMcUWxcaTSnUxhBRVGUKwNHsfOS F0oF1GyWy9As0iVOU8lcAI7ATc02HKHr23zgBQODsQoFo4jqMI2DSOg8haOo5jKMkhvLIrhQ8hMk UnRdO0sytMVQ26iQLA9FVahdXwbYrVhRXY4I2iwyjcOshPHYcOWzD9kVJZlTgbAUbxzaiZ2tHkjR +OdhQ29Fz2O9tk0rR0mPleqPX9Nc7UOjqFJXTijtgmMv4QodI2nZWGyrNEwqLg2GIXN87q7TWC4t P8TRcsOOT9Q2MKjQVR4qpuSKFRIcQK3VPxNMVp5ov2YIxdjIBcqobZ3m1TWcruW0nome0vgMAvO3 Whs6GaLWuFAzDSNw0jmNGsjPYQaqbBYiMrgcI2FKmxwdH0IV7X9g3JfOBodUel0mibFZldO7ZvGs B2ki2pLBqt6X3bY826EFv3DccM3LfTh2NEG65rplm6dZ+QRxTcQ8HscIcbInNXhu0zbyvW98rgFQ OZfeZywkmYyvheFIxLzKMLifA9r2OVUAnGNYbofYTcpk4UyyOleJi/f5BPXlJWsnfZLpPh5Jj9Eh sGYXBj3qLBkr8Fdyw9J+17nvcV8OS5CG3ze6oHwaD6lRfL7f3q1+PxK5VOoy4xrVlZNZO4HIFpGg 5hvDYdsNIbw3NuWAvhYjkUjr9BsDd7YOX0LsQEtFSUFUcESWuk5YwKA3hyDI1lXCwiBAtNAq86Yc AwhpDlBBc0El0QUfdBlo67iYLwf9CBwsNkIL3bjBFtjk1JwWU7DpzC2IhPZLU5Z7DxH2xRYcbJ45 OHdPlis8xnDwVNlzY68Zj7QGhRiYOyt5yL4qo5ek+guT9I2xSYiokGr6m+qQfIDaO78o8vIaCpuP q62jmZLopOQbq0TP8kETIxTVg6BvQqGwFoag3hiBaG8MZ3A6REccnkr6ByBQuBQGMMMJoUBsWFEi UZvzpyedFHZZEXmZRUY0iGK7EI1M5cDLcyjH01PCl88VHMZX2TDlonF58fFkRviy0iOUyHZKIU2D Qkpm4/xaj3NaQ82WQPJJjNdEkTZDGbnDN1o0TZGKTBoWpRrVpLSYDSG1WQZQ5hzgXA0MYbw6oUho 5CI66ZuTYnS6xdq0ECQdnastz8IltSmlQd6VURYa0BgpQOcdBoeObnZO5BUIWzSwcewOJE56CM+a PQ5D6mwZkPLDMmajC6WovdvM+Xik6Z0vmm8A/VOKXIKY8xGM1LKfxpeayZBT2qizOjK9WnKzIpqT IigaQkTablpM6WiRRZ32VTq1N6cqo6vVVo01ClhXzdTwkuC08EJwwgta4GUModAWz7n6HSf9JF01 jq2/uhDgKcVoXmcClSEKIQnolXl11e6s1kkWjaHtZ2eUNpDYqJ9jKqV9JTYVRIMkpF7pgwmKlnl5 S5dxHqDtpLQU7QHT0tNn4xzFqFV22FRn1zLtUQuplQnq25ttLVSYMUpAwcsuyq9wi13FkK+y5FxL NMsjlc25U6jzzmJbBhz4KAiSaXEuAOgIAhwMO4hQOYIAuQkDcRtbocgQBku4eBCgXAU2WotLgG10 rnr8vtfib1Jb+UFRNZxTYMUcNUt+7MjF98CkWprMCLeCnPWhtaxvAjnqgxqqHcHBeB1MzLwrga3e GHq4ffRVEGwMLATeqvihSVYH2YslFgCOMh8T4pxlX43AMqkmJuy4wMQZYCBvDMC29wY7u3kvok9d OMImVlb/B3HlIHDWHlTklyWS8bUouo6NTeUYgtsbPRSgGSoKZMvzgJSdxJdRwwQ4HNRL2H2nTDg/ N+HKeMbzrheo+L4sYSqRmmLGIajvVzrhIvYNSK2ydtFZ8aktERdejoxOLydH6KwZpJUMh9KuWaoj lvz3UFA1WVLhq2Rcj10n2hS715gUBhk2rcNgINU3jk6CCEoIAwgghgHQNCwgWlhhYiWUhGgzZAXA GMMt8srQTlwDUHD28m2PAaDkgWiECkiasEkKYUwqhFBAC3W17A2hhDWRsOgdw364Osdg7R3A5g/h ptQEGmzKg4dNQaJG9JvQboSgfUUH4gWEbNJqTkKtvwtlchE67XtwrCCoCo6YdQ5UTcc3Kxa/d9Y3 aflzeeo+AxOzAG3eGYq9cYBzdOg2aNEPhl/HV4nK2g5wz6xGm/MGh52wmw3mxEs9Pr0oQ3mPOM/8 7ZTmzTJm+iaGIWWiWfGptaOxOv3F2lOoy4rA0npnUunUHNx0h8yfWrBPvWGEOk+QQHVWEXhtS292 HbntsuG+zeq0ZRNvnud+e7dNy1ymknS+o4E5w7zeff0u5xptFvrPgMJTB78SXwHPaudU8dVC2bz/ Epdz91jwngelqRp13tnHiPPWO8jIHefo781h9PUXfZ58dbzJ4wZqwb+x9lgYC0NkmlcHh5JxfZvq PW5P397FhuUohOHcS4tcXcL9ESbD6zrdG0coELV8XL6D8w8ViNmT3/0PQJN776czpVelErbD+O3X hsHPk/P6bxcYPxem8hpP037fyWs6GX/02gn56a/0/uemuAKktqxU8QBnAI62wzAGtK6ufpAWtW++ xw1A9OK01KDKDMDCDqDYroDIDKVyDsyAV4DCDIDIgMV+pE4ssu4xAPAY+ir+0cm4Iw+MzADm4WDc a+97BU2bBZAgaaycXe87Aq+uhGdCpG98+dB45QwC/DAWfutY8FCawY/U5pAMSlCdACTS/hCimIcs 9KKrC2z8TyRfC2/4xm6RBZCu6MtE3mx0wi625rDawM6m/rDi2jDM+dDqvyQE3kJ4JCuyCgVmgG7O 3WOy7cvKvPEAgEBACmyBBADkvKDCDcDIBACeO2DgO2BACIDKDsDS2QDm2VByvrDww2v6WQJ5FI62 3zDym85UBkQK8ojVChFcfkwbCo/ZFnFgea8ZDZFfC4mfAVFw6FDELCJ5F7DKMw6xGC6U3mNyzWcu oM5rGa7pC86XGk9S6xGs+DAmjuSk5ugBECyABaO8PA+Y3zGzBc+EItG46DBm+xHG94+0oq+4+dHP Ai43CBGZG64+sK+ydEzGyu4xHrB9CWddGqJkpPDUNZHVGaM3Fql28RIY5al3C1IjF8mM0pIrDC8t IrGO6PHpIPIkea0OBg2hGmtQ39JIJ/DnC/JSLfAS6xJbJM43G2BgRw8BG+gFHC9ylM9sDdHLFNJj D1BfJRJso/CGW1BqVnBxHjH+2Y+dKC+DHwKLKKsocNBQ+3IA2bKg625UBgLUq/Ce5fK8szIdF08R LHLBCwYyp6KLK+qAjItm0pLRFytvDHLm6LF/JhLc84BAJ0K+T7AKfJL8TrJWIXMHMBJefpMO9JAk 9eJ0JkKrJw1UgIDaDfA64pH85KlxMXKFHTL65O9NHahHKSa9J+X7M5KisjM/MgsG5A+xKvHlKyIl NRK4/DMGuc/KIxNu/S5nIfMEByK/NwtZF3N3ItLi9NOLI0RfOLI6ugkPOTLDL6PYZHHs6eQOL+p7 MLOlOzMTOfOnCU0/Mc2efOuygDMmBaW47fFDHnO2YM+Cg5OvPGffNEW1PScUBAXA+XPXNlPbOpIG b9HwL+fscI4EcNCLBTFFP7PAYFILL6BufJNyIsBpQeUlLK9DMFQoxjLUzuYbQmfI/mkAKrQ8xa/x GGQVRGQPOamhOfQyxK5dL6aGZIuMi2BpRiemZ+ZDRqM7RukKaTR1Rkh29dRO6BKMVhPMgGrgQqO5 NNM3RtDsxxPhQlSJKq+PPsPRPzQPKxKdRhR3SfHvNVQmfVPoXtSZNnSczPNs5vQjS4tM8PMFTVOG /hR1OMwxRzThQ2jWLDTnRU9VTnGWKISlS9OtQk0QIg9TRzULUFRWM3UBUNG1Mc6iOUQYVjHAgJBq 7IDKrYnsDmDCDPHhMzCPL7UTM7SjRgnFSpBpBtKXVBB1NnVHNSo5RrVPTGiHTLVFUDTRQaKIc3JC 7qeJV2RjQs0bOuLQSVTip7WAP7LhTqeTWTV6q4efWdLwqbMVWKMVT+KI6DMCUkJzFfJkTxWbWzTv P/GRMVXFW+65AmJysauyPAnvU7U/CNVbL7XPVI37Qk/0q1Vo4VKVVtW7W1HRQDXzSLNdNHX9XrFZ NsJyoZTWJyJkUbWFJPXxYfLoMLTlYWUbRBXBORYxYqmVOXY7Wmt5XNYpL4BoBmJk8VDfRpZQe5MZ RDMNZbZVOrUXNnZlZeczXVBYucasDckkDSaxJ4nyBa7SJobVKaR/E2u8pEpe7WVkyEDSDZXiQ2KO IFZPD8nabwoMBkudZPZS8La07qWRa9ZdXssBZOuHNbH5Ps+VSzNjS3bJZnXJS/VjZ3bUbNbdaQ+b L7ZvVyifZie2aLTw8FZPcDN5GdWHQkBncM5xOJcWsnY0m/ORcfcFISz/cKsnT5R9cojpFjMMBkLV ABbnUHL7dA/dATRzdNdFGe/7UZdVQW423knasAWvb0BQOaBAWEBjaMlJdxd1d44TZ87LaC7JaHBH BLU3PVHjdldeMrTgdOURbHebPfXvdLdpKOXtVVX9enYDTBFmQPX3bzM1Nne5ZozQnaK+uxYafiux YiznMFfZRdInWRfjToz3WbfrOVT1frc1MVfzOiBoBiK/DTdZcTL7gFPJO1gDgHUVT7gRgIg0Nvdk Nyc/dtd8XJd2Og4TgucdgylabI1aDHE8DmrqvEDkgQ9wa2rwopgnKoBiKLbCb1NPgfUUiRgXgTFT bHhpb8iPMMMZc7JFV/h/Ta/XW5iG/fWRiHciwzgDWXctRNgOeNf7OfiPOipaIfZwYkfJiuj9dQeT i5iy9VjBM7XVLGkfUmDMvFhIDmDqDgDghKO4bhKZfGNgVZi7Zo35bPjNH2pDe1P3S3jHVgRymsij j5QNVtkDNrQapaM66tLCeiNIX7fddJkY61TxF3kqlxiWZDkzWfY+LDk7ZExEfplDGXAPUCMofzQv QqBvlQfgfVGoNhlbJUJXlVDvlllcfxlhMaS62ooYatjSVpjYDFBqV0gUgYpEMFeAbJdsrhjbjeDl jihoBlZQNgc6nMIIRjhklwBnmvXRjzQrl8nfewiHj8cchW4RhAhghlNhb0iRlPlpjwsgo4paJLnH QK+PfFVDm6M7IRgLQZb/lkRxLTIS8FAPoG8LN7LNi2f9oIps/hoOszk3i/obY8w6pporlE0HlJoz lMj5MJZXi3o/MRZowyJgQLpJdHZqYdpRiyVS9eJg/RXaWADSrfjZjdjggfj+7izhpbbNQrRjMjnI +QW9PwcZkRpHpdnmjdqDbvkPp3b3pPpBfM/DqlOFcGeJqtcOzlkpo/qvITkxq8tjC6/oKrq1GEef rPinIbrFL4BmbDPdpDQrrhP9n/ZgNhrpdhOdIbrzjJphULPnUm1MvgrpjSDk3Gk7mdpxmjp1jnn3 r7eosBrfCtQJYLPqcRqLSxkRshe7npsBsrH5n1XnreJlrqXYzRree3Q1oLqyKlqBoVlXRTtdtXoe p7tSUlom/3tnfkz3rTt3o1daJft/lMoXR4qsi3ZQLVuMoNpNuLgaaTuTSAy3AnZRF7Z6XEx/EeV6 DhsVmhmlqhnfudp/RTXFVQ+xbZqNP1sdtHvFkEt1vLfDkRvbkVoDuS84ejazkni1QraziQYNvttz rNv7RLrTvy8zlJwHqwNhDFUUpvcWK/gbk5wZGvlJwnUeS7ZbUkVgawa0a4a9jXmfpzjlVZQTwfUd HRVLcXJBvMhHvRs1vAmbwts6jdwzkNnzkRxlqpkWLJWvkedtx45lcRYlwWKZk9LXv/yBfs58/3yT f1wxyLuBlvcXyhlMJbXHrtkpytXRpNy1wokOTzixm/SENhdNX1UmnxA7xBsXu/vXxLy7sjQrzLYJ bXsxPvxfzbPZzBYBnk44apL3vjxhklzfvph6Nhd3YZx8wZ0PYhCnN9Qr0XotQ4t10hyVliTyM6VL Twz/0uoZrWJf0plML7blyxv3RT1FjDk51Py9Ib1Vwv0NODNbUogEVq1gV0DSntu7xFkR1bxReqlA uTxZsu+TvTtFxL15z5Hx1/Z5qH2Lzz2PpVtQS0snTWKmSkN1v1wd2lcrtrv/21rHF/1T2tiBLrlB 29yjXLy/3NGWIiQLB6fSflgN3ZBaIxltrKIX3l3d3rI8cUZ33zl3Jm9eBljtfBUm3GDwnmXEBbSP HCDmW7sbxJPZ4ERxdXgjM94EfJX3NJBu4M2Cf+4Sn6V1nbjp3xr065Hx4uUl4zVt4ldPx1oD3lgI inlqZ2ff2wi35ht4i+p75x0r3t34QL5i8qRf55095/hxwUx1tUfR31dJ6TRJ3p3/Y2Kr6dtp6ZpX 6p6X6jXT4Dlnsr1lPOgMgRmODdzVu94fXlQSs8JlDl16sAs9Vx4znMPJnQ2F4+a0k75WfNtp4r5P 672CR/2bP57VDd5d0Kx0LVyMtFlqLnyDq51Ke/8Zca/h8OMbwD3v8jyccV8j6L8p8SYJFdwb5v72 uWeT9B1WIl9M+C3lFcNk4/gsObd/g1hBg4PJg87XMuDTEcV4PA15Mt7L11hYIFFdbSMrfVm0dQX7 9Thz+T9GiaiR+V8KSf3uj7Jdqxlr+p8bTcUlFdwh89F3+4J/8scV+xrR6H/J85/J3Wm5x7Zopvar WNpKZD/f/ZpU9V/nzExyQUKOe2R2VgDGDQIAYTkYTGdDKchaczKdDnCTqcDgbzlBjIKRAVDUDSKV AaMRAMI+IDkZxADRwMBcOBwIBkNJQNJXKBuMhAMZRKzkZRAZgaQo4NBqNRcNZpLRmLhmNhBFyIDZ BT5FJAaKDoeThOpoZTcdTbFoxGo5HqhI5LJ5TK5bL5iLpnNZvIp1PJ8DRrSRcNJYNKPSaWVKbUJB ZKnXYvGY3HZDgalZpVebVH7ZNJtKbhO6diajZbwMhmObZSplNNDlZ4OBpkZZnc+IKTp7XbZzlhoN M9RNTnhvoNRo9jPKBKJbt9XZrxvLjdBnKBtm9VuchbeNlrqMaRSs5uKVyd3qN7dBsMhcMLRzd10O 5x9NLBkOBcOfLkrf3dntaL6/b77dlO7deVm/s9znvg/Tjhq77wrQ/78MmnDjrmGIZOsGbqPSpipj UN4xISNAyoWho5oeiKJjKirCrAxCxsWm8EPZADRwW0iep+oKhqLCSUrxCrAMyqaqqulgQK0rivMM sLMMExkVvvAL8wYyy5rqGy7tTCccL8y8UJKFDCK+w6xJDI8VPVFkFPi48dSO/z2OC0botK062hk+ zgtayk2ga+caTEF01u22Djt/Pc00CEDiSW/btOXPU+PNPzpRsvk4zUvDtUYmj9wM8VFOLPtLPQzY Yhuu9NrbF75NpPIZVBUUl1LAlEU/ULZ1ZMrpUwtFVVlF1aLksMIPUlAZppCstDCPA0jargWjGN44 DSMsPRAiSKSHE0vMUssw1TWNRwFJteTvGbbTjYFhStM6pBQiQyDSNwwjZakuyNFKzpZXFuSZGEnr s/1yL6v95SyOd4SLLCTWze1ZwGy1zs1eso0rQ1PNRVOHppOjX062VT3EGOKyXO1AODijUULOz+Bd ROR4hk1HutjrUUo0Tz1q8FM5VmWIO69IZBgoQc5xbsYTxcWevboF8UO/qWaLn+E2872arRpmj1bJ 1eus8TKWGNti2PZMLwyN6Cw7gcTy/ebG55n2qV3GNwKFoj2JXHOAKndV2XdstrR3JGl7Xp18o5KE pZ5uV/Svs+A71uu+7Vo3AO7hiTM3oujzs02J8q1jlzrmbfY2ovNTZz1wOByihJpkvSZPlPRU5GDp urv09tZ0dGp5Auo9ny3SPSGIctPe+q8++ia+BKVdYV3FX+N4PIQJW3m+Q1Hh7dB6ld/UL18PYljW QNoW2omCQqYEAUbAFqcoMNw6DSN43Baq45fdEkuYJxODXp3/neTp65lAbgZIHL2m5rmbqCgMZAl1 rtXeiVeLBW+v7emqRtq+kol4eynuAq/2CgoYFA5+6138mNgk8JtrknfA5KODZjDETLOYVJCplBK2 LwueInl38K4WsgBq6Z40OlCEvhschpUOYZsfdWy2H8R2YxDdygeJcLIkO3cmTUHB4DGv9aE6CK0W IWvVdZBiK69ItKXd0DGMcWXqQVavFYoRzmttde++FEr4yQPlb2YIFBWgyAtDqQohC1AanFX8ZiET 50MPxfmRINJVXFsFVBGKLwIJBmQfGzpMMaJJxlQajKAMbjVt0g63eBkj38QRjTF+NhyILygjhAaD sH37NmhFKiTca3lOIlrJIFzHYpsZTc9SMcvoasgi5JqXp+IeQ+mRL51UVIwxdmTL92ESpmnZdtMB qEUJrzUZ1BgG51C+ScY08VUE4kyS5mjOd2U5HcPRnZOOXD/o2yRUHHF7yyVjhwJyHMOb7g3SySJL RvkmZwztnm4Ft8OAbmnODKJ/C6Q5QLbzCCgiYH9UHnlBSXMFkpT2ofLCiNAlquMoNOh57C3GTgaV NlGEMDJA3aVMV0jQ6Y0tdefKHqg1QNKmfNqddMmUL3ZZSintQ3a05ehGeoSiaXTfJqDUzx6Z3J3m PVJG9KXlxFqxVShMZpuVdhNR2eqBi2z4a8+ANqIw0hhQ0hwhkppayZrFVpt0AIcVmXLByiMpKKyz jy2glYMa61Vo9BivTh3JQerlQV/VhavpmpXVEzyD5vMSVJViy1NIqU2spL13lnadnBsJZV1MQmWV ctNZdR1RrNMWqfUusNq7YwvgwTApDbJc2eBjbhYNdp12+t00+J6mbenst/YaeoNTqV7bsGYMz8Qy hhDWC19ta6SVUkLYFLJDiILSRG2VVJILj25BADYp5d2nwRuFXZ/64TJXMdpRCQ6PSsJAK2lugd3I R2DvbcqVlH75XOsXfqksEJM3/sjSqCFt1QzKd6m8yQNMHubNdEO3mFGUWsN9aPB2G6fzViLhrCE0 JrYkqSzm2VxsUW1TcTUu0qrdzHxjcB5gMca1VuLYPHOC1vg5vIaqKSFb+AoKWCBakaHyF+fNkfJJ MZCgoDcG99oZg0wJfa+8FoZAyhsDSHYg4eQW1rDoGgN4ZFoXfRE/WgeQCag0SoSymUlr1yZx7RzO r+s7tBkxnpKOMmnwogwXZTOLnJvU0JDRzkLVTTm0Thx0tPNH4haTUjHCUdC1Kta7LS8UImsmnho/ QzvgZOo0BFuc2pYNY2iLqp7eOp4au1Od1ByvkHnsl8sMMgbw70BDoTkML4J+LsIMHKkkD5TyZ1le 6T0OD7a5pFIddta7G0YhJsvADg4MbPKVfRHaWtq2CJrtjH0um+bbNOgXSFMNx7pOzovDExyWlDxL NpkO6N6RBgnUDG+891aGdiXxB+7sUtHrBcbf29aXwYxwauqtvOGnOx1jfiM6biTw4rswjutmXqJy JAfKeVcrhhyy/BagN8oPlsWGXMD7M0ohWnRa/j1ya8Z5RnSl8meM4ArwbYGPHUq18vqVa+6QcDbI rm/rne5bD81Sjx7aO3+jwhsdCTpeeEYaC5qUcGFRMIvU4b13CznbOzH7D160UzOz76XvpVRPP+ud o35Ubten3V8Y7juuDAMDwKLz4n+Y/fFB8TiL4LvzSMV2D8NWOenG3sNFsssMNjYl3LPu9zC8KJSb Giu3AcH4P7xPb83TxmUlz0SZ8Xxrnp8CheR6jHq+yP+jbhWw/r1O2V9lu9bgSA/U6L7i9H4d6vWi bHUNtqPCRbvjMW3hMacwMPl6Q3v8pPOlFXeF+jwCa30E892mhPD7nx9NYvyA696tnvysQjA8z9Nw 3YPR/bxrmkMtupWBR5OBIbAyrUnH52Drz5vQ74ED+Kywx7Poxr+Lni+EAaFaxSA72IrK/L2i/sAa lx6rpr+kByWMCZvsBLcrrTNz5A1DNyzjeyLkEL8bSI4LNz6xRxpUFDFTTYvkEjgD+C9MGLF4G4zz 9yqDlC9TvQEEHyO0FLdkITRTC75xPMHR2jh6LkIz6TD0II9h8cFqrapEJcHj68K8KaHaJKlEJ77y oB6MLC4EMcLjSDHcKUH7QwucFh3Tj6DrJzzTlLJjIwpbJ7JYIh8wOZDYhZZQN4Op9hssFihzvb0r PIxsMiqpvsRTcsRkHauwgIANZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iag03OTY1DWVuZG9iag0x MyAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQg PDwNL0YwIDYgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMTQgMCBSDT4+DWVu ZG9iag0xNyAwIG9iag08PA0vTGVuZ3RoIDE4IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0 cmVhbQ0KgAwEECgRyM4gBo4GggG4xHIuGQ4gYuG4yicVEByMogM0JhcNh8Ri8WGEUi0ajkek0Mh0 QiQzGw0F0SksYlEdGg0h41i0gl0joE3Bo0GslGUflsiHElhc1k8bjo1GclmMskM0ldOjNQBtSGIu mFWn9TrMroQ1GwyFwwiU+kVarVntNrttJrEYuNchUMtguGl3iwxksSoU5nc9vt/oGCmdblNSqkfx OAEGMwlctFqtl8HF+ymWx0dwY5rA40kT02Eg8qjA3yYgmEyiWgoRCKgNGM5llfsIgKhEBsEgcZ1Y vI0Cxmb32iEG+MfD3x3EAoIJ0OhyNJiOp0jZuMJtMop3xqBpF24x4cF1deFwxxGdxVa2lc0el0/1 4kIolGyXwiSlr8yrBtCBrbKGGoahcnjdrAGzmt+4L0vyBoUDmPI3DoMI8PEKjyPM3EJIMhD2Pczj PMXAahPxFaZtPESuhm3kHNc/zYPlFKuQMqQbQChsZQe4DhPUhEKheNsOQ888QvXGL2vfE8bsbFUl oQvbXBuikHLgsy9Jk1oYSwG8HNixq8pSw0FMRMMtLKmyuP2iDJTWEEAKbLjHrIqsryyoEzKjJqwz 3MUbTap7HrmzdBTYvE7o6vYbBzHlIxRKU3p1NIQUhSVFsDHE8MjTNIhdScosvQ7NIlTVR05AVKpT AwcoFSCHr23zgPQ4UXhQ5oQSQ3CaSA6deV8GNgVs6Y4OxDAyjkFo6DS8A3u2Fo4WYNI3jJX0P1iv jAhsrDFLPJsS1VUiVvnPCv3JUVzIxdE/3Ui1y1Zd8I1y1dH1Eo8+0a1l5X0hcyMowtLwXVV9y3N0 zqLONQx5fc6qCzE8oXg87UZhV4Qbh2GrJjFDKjRFU4BfmMo9TIcQS3VSwJNGDZSv2L07V0/1Bb+V ZlVtTZDVGUZxSmdxBe8R3HeWYZXc9PY1cmj5zesSaNn+WSnoeT2/LySULAiFJXq6V4FiUz4Lo2sZ LkEDv5lGy4jP0YZtrmP7DjSw68jGPazkzMrptWtbbR4bBnJygBkr8HYIw9M8BwStcIF3DYnm3FRL xnCwJvTNhtyW8ItxvH1e8/MTExtbQoJQ3jE3wyjaOA2DC7gQC4FHXOu7LtjKOaODkN42hAOg0KgN 42DYN47jSNyDjmMox2eN43dwN4zV8FtihB6cB2OFHTDELgU21JWq6hxPA8npOaRheNMhvwIc83nX LaL9P1/beshQnv61Zzv2y8z/DYJimVfrLl5FzfzAFhi+3+IBbYv0yDjmKwEbM+9H8CWAsJbO5dVM EILNbYqDVyrU1LOIBtB5xzQH3s2hIvRpRXWRKZhTCY2p5wZIOhGTIxTpHsunBAHN34ZQ6HNOq7Q7 R3A5veaEcNF74YRwffK0GJUL4QLpcFEuEsUTmNVUewwHBlH9Ndi0S9/7A4QqYhGYOLkBm0xlJmf8 pjcm3QOhdGaCK4oJxfUI3EuTPY1Rbjml1TINCSmbisUNscf5AmfhXA0qpMZDwwMxC2Rje5BoGPdD QGhalJw4e0CAIodgyoYBAEgMIbgyBseMQeIJ2Ihu3iMriJCTH0SRkFE2CUU5ASSlpHSW0jZBv1Re o8GZDywwbKE3BeUwWNtgbbAJTMyJhtaMLAdiszkHQLbyxSZswlWNtPY3Sakd32x5b24CbUfSUqPI igqFT5pmFpM6WiRyn44TunVPFnk450zwknDKGiTTdSah0FMMbvwyB1lM8cEASXnHXDq8ta7zgQSp drESVqVHzxTnzOuJz8J6T6lyxOWNGZ7L2lelVioMksF7mIl1rtKCZsBjDG6dtLqVTQTfNJTNNCFz WgvNgtNKYCzXgnTqcEboMU5qBOZRzFQYpYBg06Fc7amlrqg+aRVTKnVVidJCqdT6RqwVkS19iQIj pDQosM8avzoG/WEc1Yixq2K7rdWl6hAnsBlDwGMMocIfhuDfD8NTp1qLKDoC0MIZjuByiMtwG1XS FuEIIieXS5LHUjiVZWQdl6s0jl8vipiPAZvti6RixtoCLTKgDIW0pYLRRoYbau0KdI2zcp8DG01S qLt0ttayos3KuW3pXOditT4ALuK+gtw8ZLiGfuPT1m1yzF3NctJC6B8rpQxNxDNTJiayAoCIG8MY dTwSgCg7qgtDnm0JoWHKhrzA3UROtKp20Ra0ofldWaJQMEEoLszRy/SmL+yxv/fyj5KbO0mu2bK3 ExsEmNtQyadt1abMLjTdCnkJ554SjxSBjYNroN3qNdTBVwalggBqDmrUHMTA5cCW/CeJcT4tjOyb BmMSx0xmXIXE+KbkoLxti7DeFGG4/jYgG2ioMd2WmxkS3E3UHZMxBb5nuSbMwtyZiSFmU8WE/yxJ S7WJ0eR8hxRKVbuAzBvDkCAIbzZPByDnQ8ED0HUh4h+EYNIbJWX1e/SWi6JcqYFaWRbP67pEvw0G zNoKBsPYmZgb1CGB0KSXV8QJ6zo64g0Bmr4qb1TQPYBbp/UGodRaj1JqXU2p9Uahelpuu2lwaaT0 49fS4NdNaU07XEKjvyOPBeG8WhAaXcO+I3KYOcP85OzvlEQEDxXfFbDtsCh7uAw7Bd+HkEAYQ4LV DCRpbNaQW6sWCCgGgNta6x0sEQ6bxne66CcG8OxlQYgsMqDlcwOQQZtzfel3zrgQBCh0EhZh2K/g gWStihoZQyA61WcJ7ANAb6w0qRLhoONy8R3DrnYEO3lXuBAGR24Y5VO33WRvZFE+RSjDJyMNOadp hzvAGl13CN7hhDYHXkW+w6cLrXujcQOeK6355tsjYcNt7GDNyMEATAiBQCDwR3QdLwPBBcb7XWxI fhiDLr2HYaHibUI26cNXG9pSk51q3nhRef6y55sLle1748m2pvzoQIHjBj5rx7lOzA0bq2FDsMYb 1q5x6O77jPBeod/DZwrb24HsQeoq+B+HDobSIfNoogXDksaOSDRYFBPOIdAOmVJXxiuLPYk3mS+b 0j47hBrq+tLmdzcSrjJuhWZw5BtddQ/ml8Iheprot/nZlfOOwQrD4EAYtrd2DTJ8Oj3IjAyxQCAn LPVzLhw4iX6cuNCeVNvosnJMpM6P84gjtO5/hNVrkr2ulcOeVoQ7Wrs1bf1fvrruGwIYgWhp48hg NIZvlrFM9AGluNMLbgYgZlwKNn0NMCvsgNEECPLPpAZiZLbKyNIPOtyK0i9vSq4v7gWlfGEFgr7k JgUHiA3FmJWvgJLr9rTrIvrHPjcDTpLnAvNEKM0A0gznjHXM0PiJRtrjtnfv+AxuYuUg7OaObPnQ AiHCJJLimCJLICJwXNAvpAZQmqvvuvLgZQZkHHSQLAauHwMiFwNueQOjvDwPHs+HwpACHvgJ9gGv vD3J6wuPxuKK0tNwxPzs+P0q3vgw9P1w+P3DyP6nsQOwbQcDvFnnjgWuuNirFiBJgjOo+Kmk7Qos +rTjSI1wrQ3PLgYCvlBw5P0MTvyvZN0QRFdRAP4NwxTxBPZodPas0PcL3PdvUNlHYnkurtrLynjL EwkP3ltxHItm9ipk2RKHwwDjOpZvttEwrjYFYlVwKvOMPRRQQvhq5v6P2P5Q9v4w+xrQ+QOv9PmP +v/xGjYAbksCRQDQEJakSgZxysuNAECxlwDiSwKRPw8rGxpFjxSjVxtxAxrx+RUHsRVR/RvP9lnv /FmAWnmwPK6JBNwlpA6A4FpuPNnq9PiA6nkuUvkM4lqg5QdA5ReEkwBRHHMkTgZvWwoQEnBCYEeD 4x3wICYJyx6qzAUC0lfPYQ7gURclls0gpusuNs4RZs8v6Q2Rpv0PiRbPjvkpTPmSQDyjbvoGAkEH HCJPqyUx1ypQ2SXR4gap3wtvxP0HAFfQNPQAUFkxdSEQygygWiNA4ubNiuEQzr8H4QJDZPKRlRND YOHE+SZQRiYx8K2R9EiSBQ/xqx+zCP5zDRtSHyIrCyJg0q9S1gyy2nbjuNuxejbluAZwJG9iHGsx iS5zNxkQHLsNFzNFNxnywNaPXkHScJNgpkMg6SLveDsFfFSNwsytyv4zAqzxavjSNSdRdnuwAgZE FrQsZEBTPSrLTwsx3RkwHx4oZj2yvPNywQMP3yxu1Dprwg5CNEMAWwOtiuYnpKVNwgbQvzrwwyyS zSdvRiSSiw8r6TLlfkxgYEeLSSUTnwYQWCZJ4S+FdLDA5s3gzwTTLDySTzdRqAtgQM8PmgZUHHcA 1gyq9u6Ifs3nVs8AQAuvntxkbHCjZqPTPn0Cp0PRMzSriT+yvx7Q6T0PYtwg5g6gxA2tgN8g3FnF oDwtvTyHsFISxT0zszdyyrCAWqBnlA1g4A3xdJWjdCIkEkSyqx1HOEATRH3TSCBCIpMTpqSSZjXU e0WxBrBDwUAgwgzy1AzHdA2rDAyUZA3NgDryPTximtwiG0uycO/0LofKH0bQzUc04nsCK06SyTwT YS1CNNpnmz4yQzdnwijksSsznUqgQTiCS0UTqQ8n1S/xSRqTESAK4zBxtVPNwloFknb0aA50hndn WIfS4QAluQsswjZilz8LJnOCYRMQ2tFwsiHxPUU0tvXP3w7PQUgVQSAzC1OP21ixVueDwAyOYAWo eUJA6VTU7VUzKxx0HEeDNlixhzlVIzo0pl6wIUHDOvw1K0tzVVftbUf1NRsxU1kR/Vhq4g3LxOsF mnoAWgyLwLxPmVESnSRVuiSrYrbR01Z1IgYkEwG0qEcxlnCDOx6VeQRkxVAV1P0TwUYUZUA081p0 GUcT5DcrHgYHER0VZPrnOLiSW1H2FS8QqPM0swLRyybTWVgvOJN1nofFfUDxUybQ+JNgpHbqDVop QuUKDgzpWgcEHQlFzwqWRwXxhN5keVKUtQRzZu4WYPg1hTexbgQPlSmThWOrtCHHAvgNFwqihR2D AstvgUn2CWwSp0SjkFRWoWXUVjyTsPzAUTwIe1o04Q+AbufQwUvTAPOV8LwrxrC2a29QkjdKmksU nQW1uKmme1bjkAbvwWWvOCl2qzWodJOvmWgpSWh2pzcK6XKWrPh2sSk2tSlkMSmkPipjkLGif21W SDK3YWEVwRlrbQJ3LP0AcAY2JW7K/SDTHvcyFOCv/M8FiWlUESjHYg6A7g33UuWuRM5AypPEMV+W RRtN5OPJTM2g8vniq2DQqwlWlwpXxEoStS8WDQtTUQ8gcAZVMQ8SZ14Vj1N1kxsQ/VP13TD12HsD wOc38twuuAyHnthM0t9r3nVAws7triUAwunHTs8HeO9O6SdwTYAP3yoQ+XWTMDkJkQUpZ0QnBQDQ 1y7T8tFjci1W43LtMzV3AOeTXUiKC3QKFNir2L0KISg1+VxXS3mPi2s2t3V2uyQyTCFj3RISqVt0 oDKp0o+XJDKkm1d1ywRiFXfxRjpwOuuA2UCgGgW0dK4mU4rP7LBSzQbA6Xv0+Q+WjYxR8vOQOz1r CrDrE0lYjROFMFuWyXZlRWTzR2UtFt6GNz/R9gcTzjyVgWJw836X8RuX9X7R/HtLBxdSEgzAzFqA ygwg1xxmYPgLbTk4l5N4TVIRgYV3eW5mTycQOiNDuP+XilrFsW9xtDTIjCAgDWVuZHN0cmVhbQ1l bmRvYmoNMTggMCBvYmoNNDE0Mw1lbmRvYmoNMTYgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVu dCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiANPj4NL1Byb2NTZXQgMiAw IFINPj4NL0NvbnRlbnRzIDE3IDAgUg0+Pg1lbmRvYmoNMjAgMCBvYmoNPDwNL0xlbmd0aCAyMSAw IFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAQioDRiMBwIBuMRkLoMIBAVCJBBAMI mIDkZxADReRopBYZB4eZgbFIeY4rDzuIBQRDeYzqbTKbjKdBTDzUDSLA4LB4SNBcMhoIBrQRgLhp BzkZRBIoFBBsMoRCo/DogDRQICCdDocjSYjqdDKc5qVJvOadUJ7P6CNhtE6NSKVIhxRRxPBgOZ/b hvUI9cKWDaaNopCYXDYfEYpiYtGKsORhY5vRxALb7VCJKpZLpgbjoICJYTHXDgdDSbzdWK1XK9YM gDRbkpJEJUORjrRxQcpdMtKjJLZfMToLTMbzkbTDNJtOJ1FYpF4zcxddRANhwNxdbaLexBlaTf8D FBtjrflpHzMXGRQORlttxlcP2/Nzqtvc1wBaY9NYM5rbMMRotYcBi6Kghy7Dxu6uS6IOGwbhs6K9 L43UEMAgbBOmG68Oo8jFOaxj0hm9jJvc2QYvjDytjCNw5jMMo5BamA6DQN4yP4nT/wvAQYQIxMDr iBroOktkDO07kfO+6bqOikCqw487Gho1rJNzB73xKxT5Kuh0aoIhq2KKoDtoOorJQmpqFLaGwahw qbDvLK8PMy37OBAKA5RmOoxtI0wQCTFStzxPTTqyrauq+sLWhkGqoNiy8rIrLAQC4FA5pmEAxDyE AxjYNLgC4FMthmG8FhqGq8wKt0yR9IFR1LRYXSJCUjQq8E1TZJkTPQHIataGaKSnJdG1wqyHBA1o YzE3cs2K5NjpO2VlWNZD3hQ+k5OC4biuPLbHOm/6jO3G8xr9BMlW6nyiVfCMHzLWduusGVgTdR8P QLXlfRHYM3vRYlo2cy9oWZaVn35gN/N4MozDCOo2Wu/NtvAGc1hsoMz1RccfwU6YZhm68IO3WLvX aGwZwcyU2ybLAchvENft3R0OvRSmE4W4Mtv8tYZOs24QNhHuQoI9Tp0S6945RDyYDINKX147GXWE FAW0oNgyzzLYZXhoSFoOGlXVSv9V6zB7s3Vi8jqfUsNZPp4chxll8JUNyXjFFoWjqODWhbndGNmH O3N1aYzDSNw0jmNHBDPvFub2FCCse5NuZbaY5jSMlDuSFvFWSgra8fe+/xJp78DhTixOTkmDBR0Q 8vuN46v25L+rmoTbuutcea8kWbqFDGO9PcSLVVjIa95IeyeBn6h9mheTVvfSrIK9fOxFz983m9Ck 0o4I4K4zkW5tG/h45ndRYt49yOkGskzFdOP3XWQG+T4cBbT5vreeGEQdMtvI9B52AFkIIwJf7BIA LNcXAQm8BlkvbDSv1xb3UXPYDeGwr5pQ3NRDK1NqrsCBrcVIQcGSOnyoTbBB9jyRXkFBfSxltT/i CpQf09NKj/X7P/gTAIlUCIAuoh1ApacDDOAtDiHUMKmw6B5YeUIGi7ztgza6xeEsSy8tjfa2Ugb8 QalFMM/VmD91dwxf49WLsNodwHS0wWMyy4Cw4BQHAMIZwywYg0ciABZoPMkW+Qp28UHhR4XQrB90 KShAzLw1iFsNSCg2aZDJYB8H/Q9jZJB1CgzVKGDmUs4kaibuZWmEM0wdkWuTT2G8MxDwyh4M6EYN LU3SwFXCslSKk1KqXUyptTqn4OANg80MtrJEDO4YwuVRTaITsgKZFeFS8DxyHjGQVlcYG3svSdGS HzA4zxrh5NeG7qA7uURjEkGp/kHt6Z8+cg84SfPrkBFZ+EKgYnWfoYhp5O5FxhkdDWSUaYHSwm1G VZLUw3Bnm/LmD0InFTlmC+iEUVIUTHnaUIGCDjpTMmmQVvs0HqT3jHPmfkmp/LTo4tNqYZjgnGIu 4KJINAcscL5CGEbwVy0qpZMWQNDnk0qQdFueULiCz1mi0+kM1qPTVgHP2ohKiuBnDRSUMNJw3UpB w8s7YMpfx8pjVFb9DJjIUoeUdVrRZ5gxc5AB089ppKQqNJGtM2ahxsDoG8OCL6mhnpRQQikS35nb P9S9r7Ga8Mdq1TWrlNwbrnrBTx6NZH90/kfWufUaKOz7WmGIN5Wg3htrlU6lJgkHgxidXyczPLOT qeMuyrrI2iIbrC/mxUjGnWNrbWyyVQrZr/KSHAMpxwyhkBaHQMIYmo1vDhK0ssHa7xZO2U+0FCWt 3IsDOym6ily0USxWKGFrazVAsdZGyFILtrTDRblyqLiwSopTIQvMerltgBpehV063zWDKCf8wth5 EAxi/dixk+Lv20u7f6bDizh2VbpeWOlxZdV3mUxSlzv4SV+wXTS6F8wZoCkNFyioMZFUYhnGKadQ ai2xsfgFZLcQ2tzRdG6OFxDlYJZ5O9jrFcHUwOkDTGDxYq3xKbTeEMy8MXVnfT6jNZ0PYghzf3EN tWDszYYcJh1dmeURs7VS9dfspWkxzaam5d7U3UQ9WJtuHJG5EX3kjI+IruYkWm5XJhwQxhoqaGFP LdHsxJkIW1Y8e74tgzvhLHUyAQSETXRPH+XwY0Xv1kO7WaLvaMwBNtxZ+HuxBOIpwzhx4LZ2Bwq2 5L65gZ803FN9lDb5aBLqranciIQmtO1dl/wSg3hiBAFIsLrQ5BjKVqyNicTNmdCHnAOWciwFcDma QMeLCzQhKCqEvCN3dYzZ+DMySoV332o3JRQpYMWFsYNmRYaknsqWiRLliqoVzkI08xfG2y7CrfZ7 p9jO5qs6jq3jvdm1bVQuBlWMm9Zb90bzNNStWjsk3/X+9slpYZLh3cNm8EHCAyJ4LCnQIgTClyrD KtFpq0wdyYDkCAOqlAQOCBAHPN9u2FuHWMxF1Cns7WoLaDQGET897x5hn7LWyy2Y+1TM1q+QsO0a w/wHI3AnULV17k5bOB8XOLbqpRGmUAZ3SIPO9dG8Fy9Ta1zh97yepto2tRUGVrJNue6CCg4ZnA59 Pt24kxS0yFXX37YvRVsMldGxHpBZOb845zRc9ntfIe29SwrelDW0LQsbwt1yQTGyfU6Xlz6/PZbX LTDaa3jaz7dhpDD2zqMdTlvOz5j2P9peu7L7GT/sN1aqdAzHovu/ReiuTcr4HqGdsuZ4r34i5mgf c+MptssqTzOe9imfonoO3u8Zp71o3u8QDgxDiKGmI/nokgybZZ25XvGwfY0H8DUqvX5+ry+vD11r 7+cEzP7HgLgXBuFcP9bKC8Oq8s+4xn+n4N7Ag+xCzQo9AhTRDubyqGjgD9T5b5zgwlT6BuiCSChQ L+T0DFxnKJjQ7mjB5csCjUS+DnL/g6DyBo0ABXr85Kr2EBUBDR6j5Z6t63wNgFoNTWIFolosAOjZ C4z/jnZii5yhD7sHL/TQCqiQr8kETfgBrfzur9L9kA7osGC4ANINp7bhSCx1h1zpiOwihRKYjqzK sDJUiwDeiwT/ZRJNb4jyKiqJ0EkArocJbojgMJpF7zbzpwoMomcKh18CRbgoCdJMLPUDA6UPRsUM DCb/iKSeMMy6pjbVgqDVyGrXg4AEAKa3wOjkI1BQg1Zy0CRirsYvCES/CqrmsDLaUH6h7saiUIZ5 7aUNLDytENkVru7pA+xSiIYmLXAFrEzFD66ZRMDQ7dMUEP71K970yQRq6nMU5xjqcVToUVju8RxO aTzScGpYzmaHhSQ0wpS3Dj8WAzjlz+b4b/kUT+8DMby57P8Ui/D1TfKRBkkZL5T2TgMW5uiUgFsb UaL+YGCvK/EPrGiEEe8L8Dj07/hHTnkQ7L5UMdkEzNUFKo5ag3zpLSQ/QzpSTYSIgNhTI/I4CS6T IMLh444NB4BFgpINzXEbkPAjo8Qg5kkfSvpcrQ43UckDrQ5jkQ0EMVDMKAB5KewFAJ8bDTBPbbES 7FgFp5Jxaz0AQBrVpt4FCuBFsnqC4NglqIrjJy47UojmURUAhf7NhhTJpypTaUAOR1YMIMgMh7BS koMqhzTGw1snEpJOpwTYcSqSrbUaSHEdpSRYxRZZMtxOYKZFsr6S5FIMgEAJ4r4OAr4zwMoOwNLX DFkCzlqXECTfbPEQr/ggsLg6Q/yeEUZ5MfMgcmhxhrkq8nMBhFwNwMImBmxYRsCzyiUzZii9Emae a9sg7u0E7os0gFsp4McpqJJiqz0C8faqbHDUj/YhTQcYxm82kJM2zgM3ANpGaDM3sc4vj3cHhjKs TTkl8gDMDVEgkAAGjycIzuj5MhD5shSNhu45LzK20t7AoPK3EGzFyF6PM6rrEzEgT0rLM7YGDfDL 077DaAEpCjKNp7jYa4K3U1L0RjKlcf0YT4IEBAsz02T48AcRkA0JT59ArOkSSOJEJxYmAOYOaN8q UkoECrDqr7c6xctE811EzsEdKZoo80UpNEFESOFBJ+xsEqkQUcp5LdrQj4q6qlRLYgINZW5kc3Ry ZWFtDWVuZG9iag0yMSAwIG9iag0zMjA4DWVuZG9iag0xOSAwIG9iag08PA0vVHlwZSAvUGFnZQ0v UGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0+Pg0vUHJvY1Nl dCAyIDAgUg0+Pg0vQ29udGVudHMgMjAgMCBSDT4+DWVuZG9iag0yMyAwIG9iag08PA0vTGVuZ3Ro IDI0IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVhbQ0KgBCKgNHIwEA3GIyFwwHAgEBU IgNGIgg0GORnEANF5GgwxGELhsPMwNg0PMcUhxUO4gFEOEAph5qiUNksQlkumBUmQxmkpIksNxvO hpMxpMZhoZvNwtOByN9FNhlnMyIsDgsHGA5FwyEAxGo2iguGkNORlEEjGozGIuhNYrVcj43rkeF1 ks0jgQNGo0g8JkE+kkoi0YBoorwwqYNGdgFt0kM2icVEEXjMth2Jnkoh8/y0vmMzzU2FBhMZjMpz OYtMdKOlONgtNhpOZ0xNVgkGGw5HFiro1itiu1nvVqtlc3O7vlxucf4N4gd7rFrGWPiOSweVrwxx NyEGN5k+ruCyeEFFNNJuOhlOQt85poZh152+B1MotNRvMW1gcJsG5hQbL4w6wrGya7uGta2hsHAb hcsDlK676yuEvLoNyj8CM2wLJMowqvBk7auO8urwMilEOPKOTzvS9b2ve+L5vqMg3jGOo2jK9D9I kGT+hwtYcQCHDfwJCS0OJBIbhtEcHsdAsJuevgbBurUFMA6zxuwtMQO7JjNpYMzWNSOY6jgOA3jk 9IyRzErrwO4oQBtOCwu5JkiAbCkoQUurqQ1EzyK8GjEsXLbvy7NcrsKnDPsymrOUSnTQUZLzWBbM QxNm9w6qSNw5xyq4bBqGqtq6GjkuBJsiwQ41QVFJcIwNO83hq3aGSq8UTq8GstRE6jww28kvvQ1K yjCMg8zVHc3horVSTfB1TTqtNU2SGjeVbEc61hAEGOnWtfSwG1dS40UbDINIw0pMcyzOMs0s+Fru UiwwahvcNCMhWzyXJcwW2HYtjv6GUGR/ZsBubNsEhkhSaBdOdXScvUoBlUMqQzK1b1lesR0LfDKv M9D1BaMLURnc00KZFOPjlTjPts/k3hjBgYQCGy4WfA1ozcGy22tg1shjagcT3i0/BqHOM14FEZRp Gz0BbL45DapEw3TM00MTd64PAwwbMQz7uV3rQ3RqMT1NTMd0TJqt2aveGtBjnWj60oo3NkNDzjPq e03XdtH6w0LObfD+vRDcTODmNIyNPtF1atlj945g6uK+3eF4ba9XyeEF5rXiiIT5NmthnQLGcLXs +srRydp7LrOsx1bRY8OgWjiOr4PcNPFTFvXG0e2yr1AhqeWdIebyNyVZTk5fL4e6CvuZoXIa3QDP 0FsGN29RDL0V19G+1R9F61qI8DSNsa5PFWQDmOAy7Xxzb80Gltq7mmC1PyP4flnn7VhUCP1oxV6L b1cvUdIvYn6hkTupUg1qBT4HWOxZAWUOYbw2KZDSUpvLjH2u9KsQYtKSS+AyI8/VaDxnNGLWqwx5 TPXMlpLe9B7DW1wQEUGxpe8MYGvcJu951TfyWOJNiHY9QeQWo2DoGgN4ZIMtqb4VSDrmmJINK6Dl mrxDhM4LaDWKKznLQsYhFA5EMHTodSi6OGqvIEHkhzD51r242BjDQGEORpEVqUDKHSJZmAZGSdY3 tTsHmfojJ4kJg0WHJSBcrCt/cLWYINjE6Bt4OG4usPuGJSgaH2R4cXExtjWXWNvaM4OM6JHotKRq jd2Qc5MR3iXH59zLllG7BkgE30JHirSWUDNVkKkIPLOdF9ZSSX/ueaGdgG7XVHtfdKCh8T5HzGrD g7iVrvInESchIYEBYyFKli7IuYAOFQrcgBDFmB2oaPWhvGONr34dTrh6vGZr5Q2n2PwC1GZ6Y8R/ myQiKTP1SxWVQm5+LnHky9i8dB+K1EMTEgCXKM06IDvRjWvGib4QwvjnlPSSxZT0noguUt9aKYkz 6Bo1xEce5/yFhNSU77+lsOZpLLpzp1aGuinO6WNLqIeQLdZRV1k8XzSVfOmY9yxn3FXBpLUrzw6V S4lrS5zEwItJ6W7OpmD01HvVpxRKncDjRU+XHReZ083yFNNO4eDFJAZlvN7IR+02AaVrl3N2l8wA aEKmHTScgN4B1ZgLDaiMOKuztrAZyoE819LnlVJllcHH313OQb2plb6VnThTXSqNCDiTioZXuGdf pRvXnVYWHZnp2RsKeGYpgZQwhrBaUNG1jZq1IkaWAhNboSy4trQVOlmS+V3QvI9Q5hgbr0lFRAoB QiiFGKRR8FsQA0xCDlESI0SIlSblc31tsnwbySuPVuGIcz1XSBaG4MKNl/zZBgWtmTBLg2UWlWuL kiq6nQrW5S4St0pSTnS6C8QcryGzKQVKV6yK1kflmQeKtTU3AznBXO+lvgQYOVnflPyQaH3gtHYO NlpGkhvDups1trJ5wQZVPoGYN6FVtltFeE2KcV1QeYXzFK28LHYR7fywM6g4BoDy4co5r8TTTg3N VlxizdoAfngu+GDQbUyt4w6X99k4KmnHVYHDgpkuEgM6Z0AbA3hnuZkJlCK8iRNAay3Ay8y6y0sn bnBtU5E0Gm9fZVdM3P3DJ5TbLdoTRBliEsG7E1AGt+XiTyrBMplZdpyYU1oYVNhmZBdWJOZ70gzh RgmpeLaAlt0wdLKMvk7OZ0wtSvOeVbzgx0SzMGQXctUuzkaa+L492XwjjPCYMpdWcr1liz5MqtaM q5aad8DMOLx1afDAljirgzKzFJeDNsXXx2ffPOl9caF+oXr2SCC9V6NmYHUNhQw4FRuejOU+gndQ azRmosGzpdMDkjpx+4MjdJKl5b3XGznOY3Q60Hb70SjhuNMa8865Q7OIdqa+UzTJUpjvTvaXV7ZB 70Lzs4sG9nnmAPLJx93GAQcSIXjTN8t03HTznvrKcISC1Uyvt2UOfbkbgDbEkokROD3R4UfDc7S5 UaDyLmk/ayDpkKwTCLkpwg4kZMyZleZYK+KhSQk0K4IA3EZCiRmbDAX875ylqOL503/b+MMQXDOw rBbEp5V/Y7WrFx3NUG8OqOKjkGR3CBCGTM4Ft7vrba+EkdwvqrJAHM5rQcz2G67DvbYH5lZBbAMv cnZUhgvu2J7EmJvzYXQDeud9Q0HhCrLK1narRU7PYDL1w8PBJboi4EAVkYAgCUfgEAQQ6GtDSGJT Jp59SzK1vIHHSdOlclm0Dz+dYQvxkd4PPQOc+bAr/GjxMbl4+sdufD1/sQibo4d7X26KfdHptl0J 9+uitXt6RvTrYM5ua35XyGFDQfmK3BzokxX0ZSdp8UvH2YYiHgyg2tysBktKKAuDRvvvcvdg5izi nA2gQIji7oKMwA7m7gQLxAxlNQFinvZD8AuAUvetdFRMUvNsGO+QQmarMNcGEphOyAYgcq+voM/M dnQMPMPP+wLJVg6CHPbPcPwveO6uQttMlv1ITIRJtvjtsQgpwwWgctfv7wZPUoEvGO2O1KvDOQbg itAwdAkNIAyDYg3CMQePwQFPer1opIRLcOTO+QzNrOVOwDoKUPRtuPmrjPDsNQaQpnuwqp2wbgpo 4F2NxQKvWDZg5A6wMKPwFwxQEvxJ9QXDvkdqUsmi2xHN8QUv3wXKZQmLvQ7O0MNw9vFxPl4vtufD 0AQAoCnAyRDFNAQRBjWxVKPvvQewyQgOKuUQiFpOKsZRLssuXPSPCOYwYvEP9PqNjRQmtRFQfQFm ngQAhilLpK0OrwNgqAyg8QdAjA0iovxnfCOjclRGAw0tpk3JQMIO/tcGYK8OyI9pkCZCDLkAUI9v DCZAqAVCWI9stJqiAg1lbmRzdHJlYW0NZW5kb2JqDTI0IDAgb2JqDTI3MTANZW5kb2JqDTIyIDAg b2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0v RjAgNiAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAyMyAwIFINPj4NZW5kb2Jq DTYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMA0vQmFz ZUZvbnQgL0NvdXJpZXJOZXcNL0ZpcnN0Q2hhciAzMA0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyA4 IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2 MDAgXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2NyaXB0b3IgNyAwIFINPj4N ZW5kb2JqDTcgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvQ291cmll ck5ldw0vRmxhZ3MgMzQNL0ZvbnRCQm94IFsgLTI1MCAtMjUwIDcxNCAxMDAwIF0NL01pc3NpbmdX aWR0aCA1OTUNL1N0ZW1WIDEwOA0vU3RlbUggMTA4DS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQg Nzg2DS9YSGVpZ2h0IDU1MA0vQXNjZW50IDc4Ng0vRGVzY2VudCAyODYNL0xlYWRpbmcgNzENL01h eFdpZHRoIDU5NQ0vQXZnV2lkdGggNTk1DT4+DWVuZG9iag0yIDAgb2JqDVsgL1BERiAvVGV4dCAg XQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIgMTAgMCBSIDEzIDAgUiAxNiAwIFIgMTkg MCBSIDIyIDAgUiBdDS9Db3VudCA2DS9UeXBlIC9QYWdlcw0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdDT4+DWVuZG9iag0xIDAgb2JqDTw8DS9DcmVhdG9yIChNaWNyb3NvZnQgV29yZCApDS9DcmVh dGlvbkRhdGUgKEQ6MTk5NjExMTUxODMyNDIpDS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIg Mi4xMSBmb3IgV2luZG93cykNL1RpdGxlIChJUFAtU1lOLkRPQykNL0F1dGhvciAoVG9tIEhhc3Rp bmdzKQ0vS2V5d29yZHMgKCkNL1N1YmplY3QgKCkNPj4NZW5kb2JqDTMgMCBvYmoNPDwNL1BhZ2Vz IDUgMCBSDS9UeXBlIC9DYXRhbG9nDT4+DWVuZG9iag14cmVmDTAgMjUNMDAwMDAwMDAwMCA2NTUz NSBmIA0wMDAwMDMyODQ2IDAwMDAwIG4gDTAwMDAwMzI2OTYgMDAwMDAgbiANMDAwMDAzMzA0MyAw MDAwMCBuIA0wMDAwMDA0NTMyIDAwMDAwIG4gDTAwMDAwMzI3MjcgMDAwMDAgbiANMDAwMDAzMTM1 MSAwMDAwMCBuIA0wMDAwMDMyNDQwIDAwMDAwIG4gDTAwMDAwMDAwMTkgMDAwMDAgbiANMDAwMDAw NDUxMiAwMDAwMCBuIA0wMDAwMDEyMzM3IDAwMDAwIG4gDTAwMDAwMDQ2NTAgMDAwMDAgbiANMDAw MDAxMjMxNiAwMDAwMCBuIA0wMDAwMDIwNTE5IDAwMDAwIG4gDTAwMDAwMTI0NTcgMDAwMDAgbiAN MDAwMDAyMDQ5OCAwMDAwMCBuIA0wMDAwMDI0ODc5IDAwMDAwIG4gDTAwMDAwMjA2MzkgMDAwMDAg biANMDAwMDAyNDg1OCAwMDAwMCBuIA0wMDAwMDI4MzA0IDAwMDAwIG4gDTAwMDAwMjQ5OTkgMDAw MDAgbiANMDAwMDAyODI4MyAwMDAwMCBuIA0wMDAwMDMxMjMxIDAwMDAwIG4gDTAwMDAwMjg0MjQg MDAwMDAgbiANMDAwMDAzMTIxMCAwMDAwMCBuIA10cmFpbGVyDTw8DS9TaXplIDI1DS9Sb290IDMg MCBSDS9JbmZvIDEgMCBSDS9JRCBbPDYzZDJjOWIxYWM0ZjI5ZWY2ODI4NjdlNWMzMmRkMDcxPjw2 M2QyYzliMWFjNGYyOWVmNjgyODY3ZTVjMzJkZDA3MT5dDT4+DXN0YXJ0eHJlZg0zMzA5Mg0lJUVP Rg0= --=====================_848721017==_-- From ipp-archive Fri Nov 22 15:42:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA05137 for ipp-outgoing; Fri, 22 Nov 1996 15:39:50 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002224874000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002224874000002*@MHS> To: Subject: Tom's attribute and syntaxes paper Date: Fri, 22 Nov 1996 15:39:18 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Tom, what does s/m mean in the last column? I was going to sit down and write up a similar table of attributes with some indication of what was required support for each on the client vs. the Printer. I had thought of having four columns (accepted by client, generated by client, accepted by Printer, generated by Printer) with a yes, no, or optional in each column. Maybe everyone else has it straight in their minds, but I thought this would help me understand how the attributes are used better. Has anyone else done this already? If not, would you think there would be value in doing such a table? I don't mind taking a stab at it, as long as y'all recognize that its my educated guess at how each attribute is supposed to work, so it will probably have many mistakes. From ipp-archive Fri Nov 22 16:22:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05355 for ipp-outgoing; Fri, 22 Nov 1996 16:18:59 -0500 (EST) Message-Id: <9611222119.AA24482@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 13:16:26 PST To: rdebry@us1.ibm.com From: Tom Hastings Subject: Re: Tom's attribute and syntaxes paper Cc: Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 12:39 11/22/96 PST, rdebry@us1.ibm.com wrote: >Classification: >Prologue: >Epilogue: > >Tom, what does s/m mean in the last column? Roger, s/m means single-valued or multi-valued. In the IPP paper, the # in the parens of each header (and the table of contents) indictes multi-valued, so you might want to just put a # for the multi-valued attributes and leave empty the single-valued attribtes. In your table idea below, you might just want to have a column of syntaxes and if the # is included, then you get syntaxes and single vs multi-valued in one column. > >I was going to sit down and write up a similar table of attributes with some >indication of what was required support for each on the client vs. the Printer. >I had thought of having four columns (accepted by client, generated by client, >accepted by Printer, generated by Printer) with a yes, no, or optional in each >column. Maybe everyone else has it straight in their minds, but I thought this >would help me understand how the attributes are used better. Has anyone else >done this already? If not, would you think there would be value in doing such >a table? I don't mind taking a stab at it, as long as y'all recognize that its >my educated guess at how each attribute is supposed to work, so it will >probably have many mistakes. Sounds like a great idea. It should be straight forward, since each section indicates whether the group of attributes is generated by the client or set by the printer. There is one subletly though, the xxx-used job attributes are set by the program that creates the PDL, so that should probably be another column or perhap a different notation in the client column though such a program can run in the server and set the xxx-used attributes too. Another column (or grouping in the table is whether the attribute is a job or a Printer Attribute. Also whether the job attribute can also be a Job Template attribute. Go for it. Tom > > From ipp-archive Fri Nov 22 16:32:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05530 for ipp-outgoing; Fri, 22 Nov 1996 16:28:55 -0500 (EST) Message-Id: <9611222129.AA24490@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 13:26:37 PST To: jkm@underscore.com (JK Martin) From: Tom Hastings Subject: Re: Comments on shortest-job-first attribute Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Good point. Lets call the values of the job-scheduling-policy printer attribute: first-come-first-served, and smallest-job-first. The smallest job first can be as simple as smallest number of octets. A smarter system might use the number of pages. A printer that rips first and then marks, will know after ripping what is really the number of pages and might delay the big ripped job in favor of short jobs. Sort of an "express printer". Remember that a Printer object can be implemented in a big fancy spooliing systems that supports one or many output devices. And a Printer object can be implemented in a simple output device that only takes one job at a time. Such a printer would only support the value: first-come-first-served (as I expect most implementations will). Tom At 11:20 11/22/96 PST, JK Martin wrote: >Angelo wrote (in response to Tom Hasting's comments): > >> Under 10. b) you list shortest-job-first as a scheduling algorithm. How >> does a printer determine the shortest job? A small file size does not >> neccessarily imply a short RIP time. > >A very good point. Perhaps this attribute should be "smallest-job-first"? > > ...jay > > From ipp-archive Fri Nov 22 16:57:25 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA05740 for ipp-outgoing; Fri, 22 Nov 1996 16:56:50 -0500 (EST) Date: Fri, 22 Nov 1996 13:56:58 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611222156.NAA28645@woden.eng.sun.com> To: ipp@pwg.org, hastings@cp10.es.xerox.com Subject: Re: Some Comments on ipp92.doc - the issues we didn't get to address [replies to Bob Herriot and Hiroyuki Sato] X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO > >> > >> 6. 6.2.8.2 number-up > >> > >> ISSUE: > >> A simpler way to allow end-users to turn of embellishments, is to have > >> a distinguised value that turns it off. ISO DPA has "0", but a more > >> user friendly value would be "none". Then any other value, like "1", > >> or "2", or "4" is free to have any embellishments on it. > > > >I am trying to avoid arbitrary distinguished values that only IPP gurus > know about. > >The question is whether a user would expect that number-up = 1 gives normal > printing > >with essentially no number-up. > > No, I was suggesting that any value, except none, is free to include > emblishments, such as borders, pages numbers, title lines, etc., including > "1". So "1", "2", "4" all are free to include emblishments depending on > the site policy. > > So "1" is just a way for a submitter to override some default that the > system administrator set up, say "2", because the SA is concerned about > saving trees. > > I think that it is an important design principle that when a system > administrator can specify defaults that users have explicit ways to > specify all values, especially the value ("1" in the case of number-up) > that normally is used when neither the submitter supplies a value nor > the SA defines a default). > > So the purpose of having a "none" value is for a submitter to be able > to force no emblishments. > > Here is the current spec for number-up: > > 6.2.8.2 number-up (positiveInteger) > This attribute specifies the number of source page images to impose upon a > single side of an instance of a selected medium. > > In general, only certain numeric values are valid for this attribute, > depending upon the Printer implementation to which the print request is > directed. Typical supported values are 2 and 4. If this attribute is > unspecified or has a value of 1, then the Printer does not apply any > number-up transformation to the pages. > > This attribute primarily controls the translation, scaling and rotation of > page images, but a site may choose to add embellishments, such as borders to > each logical page. > > ISSUE: should there be a separate attribute to control embellishments, > especially for the 1-up case? > > > Bob, > If you think allowing an implementor/SA to define emblishments as part of > the semantics of "1", "2", and "4" is a bad idea, then maybe we should have > another job attribute which controls emblishments, as suggested by the ISSUE. > > Maybe something like: > > embelishments (1#type3Enum) > > This attribute specifies the emblishments that are to be imposed upon a > single side of an instance of a selected medium. > > Standard values are: "none", "borders", "impression numbers", "title". > > When used in combination with number-up, the "borders" emblishment > means a border around each logical page that is imposed on a side of the > medium. > > The "impression numbers" value means number each impression outside > the area on which the logical pages are imposed. > > The "title" value means put the document name at the top of each impression > outside the area on which the logical pages are imposed. > > Comments? > > > > >> > >> I agree with Tom that if the values of number-up are really an enum with values of none, 1, 2, 4, then 'none' means normal printing and 1, 2 and 4 mean default embellishments with 1, 2 or 4 pages per impression. The embellishments attribute is an extra if we believe that printers support multiple embellishments. From ipp-archive Fri Nov 22 17:17:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA05971 for ipp-outgoing; Fri, 22 Nov 1996 17:15:15 -0500 (EST) Message-Id: Date: Fri, 22 Nov 96 17:16 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: Are "embellishments" really desirable right now? Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Bob Herriot wrote: > I agree with Tom that if the values of number-up are really an enum > with values of none, 1, 2, 4, then 'none' means normal printing and 1, > 2 and 4 mean default embellishments with 1, 2 or 4 pages per > impression. The embellishments attribute is an extra if we believe > that printers support multiple embellishments. This whole area of "embellishments" (aka formatting styles) is somewhat getting away from the "protocol" aspects of IPP, is it not? I mean, what we're talking about here is an entire domain of how a job can be formatted independent of content and/or data type. This can be a *real* rathole...unless we can specify clearly usable extensibility, preferably by example. If we're not careful, the whole issue of watermarks and generic forms processing could loom its head, and if that happens, we'd better be able to respond. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Fri Nov 22 17:47:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06500 for ipp-outgoing; Fri, 22 Nov 1996 17:43:53 -0500 (EST) Message-ID: <32962CD4.167EB0E7@underscore.com> Date: Fri, 22 Nov 1996 17:44:36 -0500 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: pwg@pwg.org, ipp@pwg.org CC: jkm, jds Subject: FTP Server problem (Was: Suggested text for the state syntax in IPP V0.92) References: <9611221953.AA24434@zazen> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Tom Hastings wrote: > > I've attached revisions to section 6.1 Attribute Syntax as .doc and > .pdf > > I will post the files in \new\ipp92syn.doc and .pdf > as soon as I can, but I was unable to change directories > when logging into the PWG server so I could not post any documents! > I was able to read documents using anonymous ftp though. > I have a call into Jay and Jeff who are off-side for a few hours. > Tom has placed the files on the FTP server. In closing a security hole with anonymous FTP on the PWG server, I broke the "root" of the pwg account. UNTIL I FIX THIS PROBLEM, YOU MAY SEE THE PATH TO THE PWG TREE AS /home/ftp/pub/pwg RATHER THAN JUST /pub/pwg [This is what broke Tom's scripts]. Otherwise, both anonymous FTP and the pwg account work as before. /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 Nov 22 18:07:25 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07056 for ipp-outgoing; Fri, 22 Nov 1996 18:05:43 -0500 (EST) Message-Id: <9611222306.AA24552@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 15:03:52 PST To: ipp@pwg.org From: Tom Hastings Subject: Empty values (and unspecified attributes) in IPP Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've discussed the problem of whether to allow empty values in single-valued and multi-valued attribtes with Carl-Uno. We both think that it is too "tricky" and "confusing" to allow empty values in either job attributes (and Job Template attributes) and printer attributes. Seeing a distinguished value that means none, such as "none", makes it much clearer and simpler to implementors and users alike than when there is an explicit no value. We believe that all syntaxes that are lists (start with #) should have a 1 in front, meaning that at least one value shall be supplied by the end-user for job attributes in the Print operations and by the system-administrator for Job Template and Printer attributes. If the submitter omits a job attribute entirely, then and only then, will the Job Template value be used. Therefore, we suggest that all attributes that are a list have a 1 added before the #, so that at least one value must be supplied. I have indicated under each one whether there is a need for a distinguished value to be added, suggested what it is or whether the spec already has such a value. I've also indicated some wording changes so that the semantics will agree with the syntax. For some printer attributes, there is already the phrase: If this attribute is not specified or is empty, then the effect is that no ... is supported. So for a number of the Printer attributes we don't need a distinguished value for no support. The Printer object omits the attribute all together. In most cases, the semantics was already written this way, so all we need to do is to delete the "or empty" from the sentence describing the semantics of what to do when the printer attribute is not specified. I've also discovered a few (number-up and finishing) that need "none" as a distinguished value. Tom 6.2.4.6 job-state-reasons (1#type2Enum) 26 Need to add "none" and remove the sentence: It is valid for the printer to set the value of the job state reasons attribute to the empty set. 6.2.6.1 notification-events (#type1Enum) 27 Make 1#. Already has "none" value and semantics correctly specified 6.2.8.2 number-up (positiveInteger) Needs to be a type3Enum with standard values: "none", "1", "2", and "4". 6.2.8.3 finishing (type2Enum) Already has "none" as a value, but it should probably be moved from the end of the table to the beginning. 6.2.10 Job Resource Attributes (Set by the program that produces or senses the PDL) 37 6.2.10.1 document-format-used (1#type2Format) 38 Ok as is. No "none" needed 6.2.10.2 fonts-used (1#string) 38 Ok as is. No "none" needed 6.2.10.3 code-sets-used (1#type3Enum) 38 Ok as is. No "none" needed 6.2.10.4 media-used (1#type2Enum) 38 Ok as is. No "none" needed 6.4 Printer Attributes (Set by the Administrator) 41 6.4.9 notification-events (#type2Enum) 45 Make 1#. Already has "none" value since it uses the values of 6.2.6.1 notification-events. However, delete the "or empty" in the following sentence: If the attribute is unspecified or empty, the Printer does not perform notification, though the Printer still checks the jobs' notification-events attribute. (Or since we already have a distinguished none value, we could delete the entire sentence). (Actually, we may have agreed to delete this attribute since it has to do with notifying operators, not job-submitters). 6.4.10 notification-addresses (#name) 45 Make 1#. We don't need a distinguished value; if the notification-addresses printer attribute is missing, there is no operator notification. Also delete the "or empty" in the following sentence: If the attribute is unspecified or empty, the Printer does not perform notification, though the Printer still checks the jobs' notification-events attribute. (Actually, we may have agreed to delete this attribute since it has to do with notifying operators, not job-submitters). 6.4.11 end-user-acl (#name) 45 Make 1#. We don't need a distinguished value; if the end-user-acl printer attribute is missing, there is no restrictions on access. Also delete the "or empty" in the following sentence: If the attribute is unspecified or empty, the Printer allows anyone to print. 6.4.13 fonts-substitutions (#stringPair) 45 Make 1#. And add sentence: If the attribute is unspecified, the Printer does not perform any font substitutions. 6.4.14 fonts-supported (1#stringState) 46 Ok as is. "none not needed. 6.4.15 media-supported (1#nameState) 46 Ok as is. "none" not needed. 6.4.16 document-formats-supported (1#type2FormatState) 46 Ok as is. "none" not needed. 6.4.17 numbers-up-supported (1#positiveIntegerState) 46 Needs to change data syntax to (1#type3EnumState) and refer to number-up attribute for the values (which I propose above to have a "none"). 6.4.18 finishings-supported (#type2EnumState) 46 OK as is. Already has "none" value. 6.4.19 sides-supported (1#type2EnumState) 47 Ok as is. "none" not needed. 6.4.20 print-qualities-supported (1#type2EnumState) 47 Ok as is. "none" not needed. 6.4.21 printer-resolutions-supported (1#positiveIntegerCrossState) 47 Ok as is. "none" not needed. 6.4.22 code-sets-supported (1#type3EnumState) 47 Ok as is. "none" not needed. 6.4.23 off-peak-times-supported (#type3EnumState) 47 Make 1#. "none" not needed, because the semantics already has the sentence: If this attribute is unspecified, then the Printer has no off-peak periods. 6.4.24 events-supported (#type2EnumState) 48 Ok as is. Has a "none" value and has the sentence: If this attribute is unspecified, then the Printer does not support notification. 6.4.25 locales-supported (1#type3LocaleState) 48 Ok as is. "none" not needed. 6.4.26 job-sheets-supported (#type3EnumState) 48 Ok as is. Has a "none value. 6.4.27 maximum-copies (positiveInteger) 48 Ok as is. Has two ways to indicate no limit: If the attribute is unspecified or has a value of 0, there is no limit on the maximum number of copies for this Printer. Do we really want to have the 0 value mean no limit? Or just the absence of the maximum-copies printer attribute. Lets be consistent and not have any "magic" values that don't mean the obvious thing. So delete the "or has a value of 0," in the following sentence: If the attribute is unspecified or has a value of 0, there is no limit on the maximum number of copies for this Printer. 6.4.28 maximum-job-octets (positiveInteger) 48 Delete the "or has a value of 0," in the following sentence: If the attribute is unspecified or has a value of 0, there is no limit on the size of a job in octets. 6.4.29 maximum-impressions (positiveInteger) 49 Delete the "or has a value of 0," in the following sentence: If the attribute is unspecified or has a value of 0, there is no limit on the size of a job in impressions. 6.4.30 maximum-media-sheets (positiveInteger) 49 Delete the "or has a value of 0," in the following sentence: If the attribute is unspecified or has a value of 0, there is no limit on the size of a job in media-sheets. 6.4.31 maximum-job-retention-period (deltaTime) 49 Ok as is. Doesn't have the "or has a value of 0," 6.4.32 maximum-end-user-priority (type1Enum) 49 Ok as is. Doesn't have the "or has a value of 0," Comments? Tom From ipp-archive Fri Nov 22 18:17:25 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07240 for ipp-outgoing; Fri, 22 Nov 1996 18:13:40 -0500 (EST) Message-Id: <9611222314.AA24561@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 15:11:54 PST To: ipp@pwg.org From: Tom Hastings Subject: Re: Are "embellishments" really desirable right now? Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I agree, lets avoid ratholes. Looks like we should probably avoid adding an emplishments attribute as a separate job attribute right now. Bob is happy with the four values for number-up and making it a type3Enum: "none", "1", "2", and "4". Bob wrote: >I agree with Tom that if the values of number-up are really an enum with values >of none, 1, 2, 4, then 'none' means normal printing and 1, 2 and 4 mean >default embellishments with 1, 2 or 4 pages per impression. >The embellishments attribute is an extra if we believe that printers >support multiple embellishments. Anyone objection out there if we don't add an emblishments job attribute for version 1.0? Tom >Return-Path: >Date: Fri, 22 Nov 1996 14:16:00 PST >From: jkm@underscore.com (JK Martin) >To: ipp@pwg.org >Subject: Are "embellishments" really desirable right now? >Sender: ipp-owner@pwg.org > >Bob Herriot wrote: > >> I agree with Tom that if the values of number-up are really an enum >> with values of none, 1, 2, 4, then 'none' means normal printing and 1, >> 2 and 4 mean default embellishments with 1, 2 or 4 pages per >> impression. The embellishments attribute is an extra if we believe >> that printers support multiple embellishments. > >This whole area of "embellishments" (aka formatting styles) is somewhat >getting away from the "protocol" aspects of IPP, is it not? > >I mean, what we're talking about here is an entire domain of how >a job can be formatted independent of content and/or data type. > >This can be a *real* rathole...unless we can specify clearly usable >extensibility, preferably by example. > >If we're not careful, the whole issue of watermarks and generic forms >processing could loom its head, and if that happens, we'd better be >able to respond. > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Email: jkm@underscore.com -- >-- Underscore, Inc. | Voice: (603) 889-7000 -- >-- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >-- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- >---------------------------------------------------------------------- > > From ipp-archive Fri Nov 22 18:32:25 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA07427 for ipp-outgoing; Fri, 22 Nov 1996 18:29:54 -0500 (EST) Date: Fri, 22 Nov 1996 15:30:46 -0800 (PST) From: Chris Wellens To: ipp@pwg.org Subject: BOF for IPP Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Carlos, I have a feeling that you will not have a problem with good attendance at the IPP BOF. In fact, maybe you will have the opposite problem. ---------- Forwarded message ---------- Date: Fri, 22 Nov 1996 10:27:26 -0500 From: Steve Coya To: wgchairs@ietf.org, bofchairs@ietf.org Subject: And you thought Montreal was crowded! Greetings, It is with DEEP regret that I confirm the rumors about the San Jose meeting: it will be crowded. As of now, there are over 1250 people registered. And, we have NO IDEA which groups they will be attending. It could be yours... or yours... or YOURS! Marcia made an extrodinary effort to get large meeting rooms at other hotels close to the Fairmont. No luck there... must have something to do with San Jose and Christmas (the parade is Saturday, btw :-) We're hoping that the multicast sessions can be piped through the hotel's internal cable system. But as you all will observe, we have no idea what the interests of all these folks will be, and it may be in sessions that are not being multicasted. One of the things we'll be doing is having the hotel REMOVE the last couple rows of chairs- yes, I said remove. This will accommodate more people, albeit standing. As session chairs, you have a lot of discretion on how the meetings are conducted. Let me give you another tool... uh, suggestion: Reserve the first couple rows of chairs for your primary (active) participants. I don't want key people not being able to fit into a room. Again, this is just a suggestion. I will be informing all those who attend the Newcomers' orientation Sunday afternoon that this may happen. Steve From ipp-archive Fri Nov 22 19:29:56 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA07646 for ipp-outgoing; Fri, 22 Nov 1996 19:22:32 -0500 (EST) Message-Id: <2.2.32.19961123002055.0090a1c8@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 16:20:55 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: Re: BOF for IPP Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Chris, I am convinced that you are right. However, I want to be sure that we have a sufficient number of people who are expressing active interest and positive intensions to work on the subject, as a balance to X number of people who come in "cold" and just want to still their curiosity, or even to sabotage our efforts. Maybe we should try to reserve seats for PWG folks and IETF heavyweights. We might need a few heavily built persons to act as security guards... My wife used to work as a bodyguard, maybe I should bring her along too? Bring helmets and fist irons? Carl-Uno 03:30 PM 11/22/96 PST, you wrote: > > >Carlos, > >I have a feeling that you will not have a problem with good >attendance at the IPP BOF. In fact, maybe you will have the >opposite problem. > >---------- Forwarded message ---------- >Date: Fri, 22 Nov 1996 10:27:26 -0500 >From: Steve Coya >To: wgchairs@ietf.org, bofchairs@ietf.org >Subject: And you thought Montreal was crowded! > > >Greetings, > >It is with DEEP regret that I confirm the rumors about the San Jose >meeting: it will be crowded. As of now, there are over 1250 people >registered. > >And, we have NO IDEA which groups they will be attending. It could be >yours... or yours... or YOURS! > >Marcia made an extrodinary effort to get large meeting rooms at other >hotels close to the Fairmont. No luck there... must have something to >do with San Jose and Christmas (the parade is Saturday, btw :-) > >We're hoping that the multicast sessions can be piped through the >hotel's internal cable system. But as you all will observe, we have no >idea what the interests of all these folks will be, and it may be in >sessions that are not being multicasted. > >One of the things we'll be doing is having the hotel REMOVE the last >couple rows of chairs- yes, I said remove. This will accommodate more >people, albeit standing. > >As session chairs, you have a lot of discretion on how the meetings are >conducted. Let me give you another tool... uh, suggestion: > >Reserve the first couple rows of chairs for your primary (active) >participants. I don't want key people not being able to fit into a >room. Again, this is just a suggestion. > >I will be informing all those who attend the Newcomers' orientation >Sunday afternoon that this may happen. > > >Steve > > > > Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Fri Nov 22 20:02:26 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA08113 for ipp-outgoing; Fri, 22 Nov 1996 19:59:18 -0500 (EST) Date: Fri, 22 Nov 1996 16:59:22 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611230059.QAA28872@woden.eng.sun.com> To: ipp@pwg.org, jkm@underscore.com Subject: Re: Are "embellishments" really desirable right now? X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I agree. I was not suggesting that embellishments should be an IPP attribute in this version. Number-up typically has some default embellishment and I think that is sufficient for most people. The primary issue is how to denote that number-up is not wanted. Tom and I suggested 'none' because 1 could suggest number-up default embellishments with 1 page per impression. Bob Herriot > From jkm@underscore.com Fri Nov 22 14:16:08 1996 > Date: Fri, 22 Nov 96 17:16 EST > From: jkm@underscore.com (JK Martin) > To: ipp@pwg.org > Subject: Are "embellishments" really desirable right now? > Sender: ipp-owner@pwg.org > Content-Length: 1307 > X-Lines: 29 > > Bob Herriot wrote: > > > I agree with Tom that if the values of number-up are really an enum > > with values of none, 1, 2, 4, then 'none' means normal printing and 1, > > 2 and 4 mean default embellishments with 1, 2 or 4 pages per > > impression. The embellishments attribute is an extra if we believe > > that printers support multiple embellishments. > > This whole area of "embellishments" (aka formatting styles) is somewhat > getting away from the "protocol" aspects of IPP, is it not? > > I mean, what we're talking about here is an entire domain of how > a job can be formatted independent of content and/or data type. > > This can be a *real* rathole...unless we can specify clearly usable > extensibility, preferably by example. > > If we're not careful, the whole issue of watermarks and generic forms > processing could loom its head, and if that happens, we'd better be > able to respond. > > ...jay > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com -- > -- Underscore, Inc. | Voice: (603) 889-7000 -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- > -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- > ---------------------------------------------------------------------- > From ipp-archive Fri Nov 22 20:22:31 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08308 for ipp-outgoing; Fri, 22 Nov 1996 20:20:36 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 22 Nov 1996 18:04:28 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP Version 0.93 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I promised to post the next version 0.93 by Friday midnight using input from the Wednesday call and e-mail by Thursday midnight. I used all e-mail I had received by 1:00 PM on Friday. 0.93 is in ipp/drafts/ipp93.doc ipp/drafts/ipp93.pdf ipp/drafts/ipp93.txt ipp/drafts/ipp93rev.doc ipp/drafts/ipp93rev.pdf The .txt file was my attempt at using Generic/Text print driver. It didn't work. Don, could you clarify what styles you used and how you got it to work? If someone could take the .doc file and try to make it the correct .txt file, please try it and let me know. Please review the document for MAJOR inconcistencies. Please respond by Monday, 8:00AM. I will consider anything sent, but only include what is significant and doable by close of business Monday. Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Nov 22 20:22:32 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA08315 for ipp-outgoing; Fri, 22 Nov 1996 20:20:40 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 22 Nov 1996 18:13:59 -0700 From: "Scott A. Isaacson" To: internet-draft@ietf.org Cc: ipp@pwg.org Subject: New Internet-Draft Request Sender: ipp-owner@pwg.org Precedence: first-class Status: RO A working group is in the process of being chartered in the applications area to develop a protocol for Internet printing. We have a BOF scheduled for Dec 12th in San Jose. We have a document in the form of an Internet-Draft that we would like to make available for that BOF. The document is a specification for the Internet Printing Protocol (IPP). The title of that document is: "Internet Printing Protocol - IPP/1.0" The abstract is: -------------- This Internet-Draft specifies an Internet Printing Protocol (IPP). This protocol is heavily influence by the semantic operations and attributes defined in ISO/IEC 10175 Document Printing Application (DPA) parts 1 and 3. It also incorporates some of the implementation and interoperability lessons learned from other printing related standards such as POSIX System Administration - Part 4 (POSIX 1378.4) and X/Open A Printing System Interoperability Specification(PSIS).IPP is defined as a set of abstract data types and operations. The operations are implemented using a simple request and response mechanism built on top of HTTP. The abstract data types are encoded as simple ASCII text strings.The IPP protocol covers only end user operations on basic print service objects. Authentication is realized by mechanisms outside the scope of the protocol, but the protocol does introduce some access control functionality so that only authorized end users are allowed to submit print jobs to printers whose implementation and site policy support access control. Also, the Cancel Job operation requires some authentication so that jobs can only be canceled by the end user who submitted the job. Extended monitoring and management is possible through other protocols such as the SNMP Printer MIB. In the areas where there are no existing standards, some proposed and emerging standards are being worked (management, security, etc.). As these services become more stable, this document (and hence the protocol) can be updated to reflect the integration and relationships with these other standards. -------------- I would like a document name assigned so that we can make this draft available ASAP. The authors are: Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 EMail: scott_isaacson@novell.com Tom Hastings Xerox Corporation 701 S. Aviation Blvd. El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com Robert Herriot Sun Microsystems Inc. 2550 Garcia Ave., MPK-17 Mountain View, CA 94043 Phone: 415-786-8995 Fax: 415-786-7077 Email: robert.herriot@eng.sun.com Roger deBry HUC/003G IBM Corporation P.O. Box 1900 Boulder, CO 80301-9191 Phone: (303) 924-4080 Fax: (303) 924-9889 Email: debry@vnet.ibm.com Scott A. Isaacson is the editor. Your prompt response is requested. Thanks! Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Fri Nov 22 22:42:28 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08750 for ipp-outgoing; Fri, 22 Nov 1996 22:39:03 -0500 (EST) Date: Fri, 22 Nov 96 19:14:10 PST From: Carl-Uno Manros Subject: IPP Name To: ipp@pwg.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi folks, I spent a little time browsing the Web for "IPP" today. Here a couple of scary results: 1) There is something called IPP for "In Person Payments", a variation of Electronic Commerce on the Internet. 2) The Web address "http://www.ipp.com" actually takes you to a Microsoft page for "Internet Presence Providers". I suppose this is better than if it was a porno club, but you may not like it anyway. 3) The Web address "http://www.ipp.org" still seems to be free, should we try to grab that before it is gone? Maybe we need to start thinking about yet another name, e.g. Hypertext Internet Printing Protocol (HIPP)? Carl-Uno From ipp-archive Fri Nov 22 22:42:28 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id WAA08911 for ipp-outgoing; Fri, 22 Nov 1996 22:42:16 -0500 (EST) Date: Fri, 22 Nov 1996 19:42:24 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611230342.TAA29050@woden.eng.sun.com> To: Scott_Isaacson@novell.com Subject: Re: New Internet-Draft Request Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Great job Scott in pulling this all together. My comments are below from reading the changes. I may have more comments after I read the text that didn't have revision marks. Lines number are with respect to ipp93rev.doc document in MS Word with Laser Writer Plus Printer. I hope they align with your numbers. By the way mail servers will be down Sunday due to a planned power outage. So if my mail bounces, please try again on Monday. line 468: I am not sure that I agree with your change to "zero or more Job Template objects" associated with a Printer. I think that we should leave it as an issue as to whether a Printer accessible via the print operation can have no job template associated with it. line 527: Is 380 now a registered port with IANA for HTTP printing? line 544: As someone suggested in email. The name service might have objective values and the name search software might take either objective or subjective values from a client. Somewhere else there could be a mapping. The main point that I think should be added here that there are a wide range of possible solutions. It may not be necessary for all name service entries to have both subjective and objective entries. line 593: In addition to four color (CMYK), there is 3 color (CMY). The names CMYK and CMY should probably be in the name in case some "printer" uses RGB for color. line 616: Change "Is is" to "It is", and change "recommended" to "required"; Otherwise, the syntax is very useful. line 692: Delete "binding" from "long-binding-edge" lines 750 and 757 should be indented further. line 793: There is no mention of what the HTTP method should be for the four operations presented in this section. We have talked about POST for Print and CancelJob and GET for GetAttributes and GetJobs. lines 850: Although I think most of this HTTP structure is right, I think that we need to discuss it further. In particular I wonder whether documents should be formal HTTP Entity-Bodies and have Content-types, such as Application/PostScript or text/plain. We just need to recognize that this area needs further discussion even whether it is flagged as an issue in the document. line 878 and 887: the syntax can be shorter as: Attribute Value = #Value line 904: does the last item of the table imply that URL is an attribute and not a document-content. line 918: There should be some mention about authorization required for Cancel Job. line 934: "Ignored by the Server" is this in the context of null attributes. If so, what is there to ignore. When the client supplies no attributes, what does the server return? line 941: Isn't the Printer or Job URL implicit in the HTTP operation? line 951: we may want a few more default attributes to be return, such as the job-identifer and the position in the queue if not implicit. line 957: the semantics in the above paragraph suggest that the client can specify attributes, but the table entry does have this parameter. line 963: same as line 951. Job identifier seem especially important because this operation may be the only way a user can figure out the name to use to cancel a job. line 1225: correct the definition of "#" syntax to be that of rfc 822 per email discussions, i.e. zero or more item separated by a ",". line 1370: missing header and header runs into paragraph. There should be an issue as to whether this should be a boolean value. line 1469: Tom raised the issue of deleting retention time and then reversed himself after I and Sato objected. This may not be an issue any longer. line 1541: I am not sure than these words on embellish are what we all agree to. Perhaps, we should leave some alternatives as issues. At the end of the discussion this afternoon, Tom and I agreed that 'none' mean no number-up and '1' might be 1 page/impression with default number-up embellishment. But let's leave this as an issue. lines 1555, 1556: remove "binding" from "binding-edge". From ipp-archive Fri Nov 22 23:27:28 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA09119 for ipp-outgoing; Fri, 22 Nov 1996 23:25:28 -0500 (EST) Message-Id: Date: Fri, 22 Nov 96 23:26 EST From: jkm@underscore.com (JK Martin) To: robert.herriot@Eng.Sun.COM Subject: Re: Are "embellishments" really desirable right now? Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Bob, > I agree. I was not suggesting that embellishments should be an IPP attribute in this version. > > Number-up typically has some default embellishment and I think that is sufficient for most people. Actually, I was thinking that Number-up was itself an embellishment. Not that I don't think Number-up is important, though! It's just that we need to take a position on embellishments in general. If you think Number-up is important enough to special-case it (and it very well might be), then fine. ...jay From ipp-archive Fri Nov 22 23:37:28 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA09303 for ipp-outgoing; Fri, 22 Nov 1996 23:35:16 -0500 (EST) Message-Id: Date: Fri, 22 Nov 96 23:36 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: Re: New Internet-Draft Request Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Bob Herriot mentioned this in his comments on the recent draft: > line 527: Is 380 now a registered port with IANA for HTTP printing? As I mentioned during the last IPP con-call, one can not simply declare the assignment of a "privileged" port number (ie, a number between 1-1023). The assignment of these port numbers is within the exclusive domain of IANA, and we'll have to register for such a port. For the sake of global sanity, IANA also registers ports above 1023, as I recall. So, it's probably best we eventually coordinate through them if we are dealing on the Internet. As far as the draft goes, let's just put a "XXX" in place of "380" and note the eventual registration through IANA in the text. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Fri Nov 22 23:47:28 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA09534 for ipp-outgoing; Fri, 22 Nov 1996 23:45:22 -0500 (EST) Message-Id: Date: Fri, 22 Nov 96 23:44 EST From: jkm@underscore.com (JK Martin) To: carl@manros.com Subject: Re: IPP Name Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Carl-Uno, > I spent a little time browsing the Web for "IPP" today. > > Here a couple of scary results: Ya know, I just happened to be on the IETF RFC web page today to see what would turn up when the word "print" or "printer" was used as the sole search criteria. Very interesting results. Neither search resulted in the display of RFC 1759 (the Printer MIB). Moreover, of the many RFCs that were displayed, RFC 1179 (LPD) was *way* down at the end of the list. > 3) The Web address "http://www.ipp.org" still seems to be free, should we try to grab that before it is gone? Not sure why you think we should grab an Internet domain name for this effort. Any ideas you'd like to share? > Maybe we need to start thinking about yet another name, e.g. Hypertext Internet Printing Protocol (HIPP)? Actually I tend to agree. Seems like "IPP" is way too TLA-ish for the scope of this effort. Perhaps something like: "Hypertext Internet Printing Protocol Operations" (HIPPO) Hmm... Perhaps that stirs up visions of big, fat, heavy kinds of things, though... ;-) ...jay From ipp-archive Sat Nov 23 02:02:30 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA09771 for ipp-outgoing; Sat, 23 Nov 1996 01:59:32 -0500 (EST) Date: Fri, 22 Nov 1996 22:59:40 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611230659.WAA29176@woden.eng.sun.com> To: Scott_Isaacson@novell.com Subject: Re: New Internet-Draft Request (another idea on the protocol) Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO After thinking about the protocol issue some more, it seems like there are two ways to organize the IPP Job Object in HTTP Protocol, the current proposal or my proposal described below. 1) current proposal: The way proposed in the current document where the job and all document data is a part of a HTTP single entity-body. 2) my proposal: A job is an HTTP document whose top level content type is multipart/mixed (an existing type) or perhaps multipart/ipp (a new type and probably a bad idea). In either case, the first entity has a content type of application/ippjob and contains the job attributes. Each remaining entity contains a document and they are all standard MIME types, such as application/PostScript or text/plain. Such a document could in the future become a multipart/ippdocument with a document attribute entity and a document content entity if a document has attribute overrides. The document data entity could also have a content-type of multipart/alternative (an existing type) if a client wanted to have several representations of a document, e.g. HTTP and PDF and a printer supported such. The advantage of my proposal is that the document parts are conventional MIME documents which any software could read. Only the application/ippjob and application/ippdocument require special software to process. I hope others will comment on the pros and cons of these two proposals? Bob Herriot From ipp-archive Sat Nov 23 02:07:30 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA09953 for ipp-outgoing; Sat, 23 Nov 1996 02:07:12 -0500 (EST) Date: Fri, 22 Nov 1996 23:07:20 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611230707.XAA29188@woden.eng.sun.com> To: Scott_Isaacson@novell.com, robert.herriot@Eng.Sun.COM Subject: Re: New Internet-Draft Request Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have another minor typo in Ipp93rev.doc: line 828: Content-Header should be Document-Content-Header as is the name of section 5.3.3. line 829: Maybe I missed it, but I cannot find where you defined "content". Also, as I mentioned in the previous email, it isn't clear where a document-URL goes, in the content or elsewhere. Bob Herriot From ipp-archive Sat Nov 23 02:32:30 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA10136 for ipp-outgoing; Sat, 23 Nov 1996 02:27:43 -0500 (EST) Date: Fri, 22 Nov 1996 23:27:52 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611230727.XAA29206@woden.eng.sun.com> To: ipp@pwg.org Subject: Re: deBry security proposal X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I would like to know if Authorization is typically included with an HTTP message or only if a server requests it. RFC 1945 is unclear on this point. I ask this because I would like one form of security to be where the client (not the end-user) automatically sends an attribute at the HTTP level with the user's name and ideally the domain name as well. Such values could implement the attributes operation-user-name and operation-host-name. This mechanism would allow a lightweight security mechanism that would work in cooperative environments where people don't want to deal with passwords but also don't want to cancel other people's jobs accidentally. I think that this is one case that Roger missed in his enumeration of possible security mechanisms. Bob Herriot From ipp-archive Sat Nov 23 03:02:30 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id CAA10310 for ipp-outgoing; Sat, 23 Nov 1996 02:57:39 -0500 (EST) Date: Fri, 22 Nov 1996 23:54:26 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611230754.XAA29282@woden.eng.sun.com> To: Scott_Isaacson@novell.com Subject: Re: New Internet-Draft Request Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO More comments on Ipp93rev.doc line 1347: the syntax for job state reasons should be (#type2Enum) because there can be 0 reasons. line 2252: "Print-Job-Object Header". Am I correct in assuming that this line is not really part of the protocol, but rather stands for lines of Content-type and Content-length? If so, then so them instead or make it clear that they are meta-lines. This problem exists in all of the examples in this appendix. line 2260: does this line represent the document data? From ipp-archive Sat Nov 23 15:37:38 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA11164 for ipp-outgoing; Sat, 23 Nov 1996 15:36:32 -0500 (EST) Date: Sat, 23 Nov 96 12:22:03 PST From: Carl-Uno Manros Subject: Editorial comments to IPP93.doc To: ipp@pwg.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott, the new draft starts looking pretty good. However, here are a my editing comments on IPP version .93. Hope we can get these fixes in before sending the text to IETF. Carl-Uno --- I have concentrated on general readability, consistency and nitty-gritty typos rather than technical details. There seems to be enough of that from other members of the group already. All references are in relation to line numbers from ipp93.doc. Global inconsistency: The operation names in Chapter 5 are typically concatenated, as in "GetAttributes", while in Chapter 6 the names are written with hyphens, such as "Get-Attributes". We need to synchronize this. It would seem to be easier to fix Chapter 5 as there are much fewer occurrences there, provided the HTTP syntax allows hyphens in names? Chapter 2 Line 283 Change "Printer servers" to "Print servers" Line 290 Change first "." to ":" Line 296 Change first "." to ":" Chapter 3 Line 401 Change "consists of" to "contain" (to make consistent with text in 3.4) Line 431 Change "a end-user" to "an end-user" Chapter 4 Line 551 Change "fo" to "of" Line 564 Change "They" to "The" Line 577 Change "Is is" to "It is" Line 594 Change "2-sided-long- edge" to "2-sided-long-edge" Line 595 Change "2-sided-short- edge" to "2-sided-short-edge" Chapter 5 (See global inconsistency problem above as well) Line 762 Should "Print Job" have been "Print-Job"? Line 786 Should "Document Header" have been "Document-Header"? Line 895 Change "GetJobs" to GetJobs Request" Line 901 Change "Get Jobs" to "GetJobs" Chapter 6 Line 949 Remove extra stop at end of line Line 1007 Remove extra stop at end of line Line 1154-56 Remove " After some program has merged the production attributes into the document data " Line 1242 Remove extra stop at end of line Line 1486 Remove the first occurrence of "the" Line 1492 Replace "end user" with "end-user" Line 1493 Replace "end user" with "end-user" Line 1524 Remove space before "," Line 1529 Remove space before "." Line 1558 Remove extra stop at end of line Line 1563 Remove extra stop at end of line Line 1763 Insert space before "IPP" Chapter 8 Line 1822 Change "FRC" to "RFC" Chapter 9 Line 1873 Insert the actual list of IPP attendees Appendix A Line 1879 Change "AJjob" to "A Job" There is a common problem with double spaces between words in the text. Although this is not critical, it looks sloppy (and shows up much more clearly in ASCII printed text) and we should try to fix it if time allows. You can use Words Edit-Replace feature and search for two spaces and replace with one space, but selectively on a case by case basis, as there are many places where you actually want the two spaces. It took me about an hour to find them all. It should take about the same time to fix them with this method. You can reposition the cursor in the text between searches to skip over places with lots of space characters, like in the pictures. Here are the line numbers with that problem: 36, 54, 139, 151, 157, 263, 264, 287, 311, 333 (three spaces), 491, 492, 526, 548, 568, 583, 586, 834, 876, 876, 908, 948, 051, 999, 1049, 1050, 1056, 1062 (also at end of line), 1087, 1088, 1092, 1145, 1158, 1160, 1182, 1230, 1254, 1262, 1265, 1267, 1279, 1281, 1335, 1342, 1365, 1373, 1381, 1399, 1507, 1517, 1525, 1527, 1534, 1620, 1621, 1635, 1689, 1751, 1753, 1754, 1788, 1810. --- Carl-Uno Manros 1601 N Sepulveda Blvd. #505 Manhattan Beach, CA 90266-5133 E-mail: carl@manros.com From ipp-archive Sat Nov 23 21:02:40 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA11802 for ipp-outgoing; Sat, 23 Nov 1996 21:00:20 -0500 (EST) Message-ID: <3297AB1B.29AF@manros.com> Date: Sat, 23 Nov 1996 17:55:39 -0800 From: Carl-Uno Manros Reply-To: carl@manros.com Organization: manros.com X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: ipp@pwg.org Subject: IPP> Requirement paper now up on the IETF Web Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have been checking the Internet-Drafts list and today Don's draft came up under the name . It is filed under Individual Submissions together with 300 other unsorted Internet-Drafts, so you have to know what you are looking for to find it, just now it is a few enties from the end of the list. However, we are getting there. Thanks Don. Carl-Uno From ipp-archive Sun Nov 24 01:32:44 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA12160 for ipp-outgoing; Sun, 24 Nov 1996 01:30:33 -0500 (EST) Message-Id: <9611240631.AA24887@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Nov 1996 22:28:32 PST To: "Scott A. Isaacson" From: Tom Hastings Subject: IPP> Tips for making plain text files for IETF from WORD .doc files Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 17:04 11/22/96 PST, Scott A. Isaacson wrote: ... >The .txt file was my attempt at using Generic/Text print driver. It didn't >work. Don, could you clarify what styles you used and how you got it to >work? If someone could take the .doc file and try to make it the correct >.txt file, please try it and let me know. > In addition to installing a generic text printer driver, here are the additional steps to producing a simple text file from a WORD document that meets the IETF rules of 7-bit ASCII, no control characters, except CRLF to end lines and FF to end pages, 72-characters per line. 0. Define styles to leave 12 points after so that the printer driver will put a blank line after each paragraph. 1. Turn off marking revisions marks while editing (first box) Tools/revisions 2. Accept all revisions 3. Turn off line numbers: File/page setup/page layout tab/line numbers 4. Remove all bold text, else the generic text printer driver will try to overstrike with a single CR and repeat the line. 5. Don't use tab leader in the table of contents; else it overprints lines with CR 6. Use Courier New as the font throughout. Set Size to 10 point. 7. You may have to change the styles for the table of contents to force to Courier New 10 point. 8. Make sure margins are 6 inches wide, so that 10 point (12 characters per inch), make 72 characters per line. 9. Make headers and footers look the way the IETF likes in RFCs and IDs. 10. Print to file with the generic text print driver. Tom From ipp-archive Sun Nov 24 11:32:48 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA12661 for ipp-outgoing; Sun, 24 Nov 1996 11:29:22 -0500 (EST) Message-Id: <9611241630.AA24920@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Nov 1996 08:27:08 PST To: robert.herriot@eng.sun.com (Robert Herriot) From: Tom Hastings Subject: IPP> Re: New Internet-Draft Request [ job-state-reasons being empty] Cc: Scott_Isaacson@novell.com, ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO At 23:54 11/22/96 PST, Robert Herriot wrote: >More comments on Ipp93rev.doc > >line 1347: the syntax for job state reasons should be (#type2Enum) because there can be 0 reasons. > While I agree that job-state-reasons has a natural interpretation when there are no values, namely that there are no reasons associated with the current job state (and the semantics say that no reasons is valid), Carl-Uno and I think that it is simpler and more consisten to always require a value for job, printer (and Job template) attributes. So we prefer to add a "none" value to job-state-reasons and keep the syntax as (1#type2Enub). Then every attribute that is a list, must have at lease one member. Ok? Tom (and Carl-Uno) From ipp-archive Sun Nov 24 12:22:49 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA12866 for ipp-outgoing; Sun, 24 Nov 1996 12:22:46 -0500 (EST) Message-Id: <9611241723.AA24933@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Nov 1996 09:20:53 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> Comments on ipp93.doc - posted as \new\ipp93tnh.doc .pdf Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I've posted some comments on ipp93.doc with revision marks and the .pdf file. I included the comments that I sent out on Friday about empty values, so that all Job, Job Template, and Printer attributes require at least one value. I did not include any of Bob's and Carl-Uno's comments. Scott will do that this Sunday. 1. I did suggest a Printer attribute to contain the URLs of the associated Job Templates with a qualifier that says which one is the default for the printer and have included the text. I also added more description about how Job Templates work and indicated an issue about naming Printers in the Directory that do and don't imply Job Templates. And I added a Job Template URL as a third type of URL that a client can supply in a Get Attributes operation in order to get the defaults as is mentioned in two places in the draft. 2. Since we've agreed to keep job-retention-period, I add it has an input parameter of the CancelJob operation (as in ISO DPA), so that the user can decide whether the keep or not keep the job when he cancels it. 3. I added Requested Attributes to Print and Get Jobs operations, so that they are the same as Get Attributes operation. 4. I indicated that end-user operations is not in V1.0, to leave the door open for operator operations being added to a later version of IPP. 5. I added the definitions of "shall", "should", "may" and "need not" and started to use that conformance languages in the specification. 6. I removed redundant specification of values for the attributes. The specication for most values is in the Job attribute. A few directory attributes do not have corresponding job attributes, such as color-supported, so the directory attribute values are also type2Enum. 7. I did not touch the HTTP stuff. One issue we have is the case of attributes. Roger's flows indicate the first letter being capitalized, while all our attribute specifications start with a lower case letter. To get the document out, it may be easier to change the flows, rather than all of the attributes and their references. From ipp-archive Mon Nov 25 01:52:57 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA13557 for ipp-outgoing; Mon, 25 Nov 1996 01:49:22 -0500 (EST) Message-Id: <01BBDAE7.29605420@sedep58.cse.canon.co.jp> From: Hiroyuki Sato To: "'Tom Hastings'" , "ipp@pwg.org" Subject: IPP> RE^2: Some Comments on ipp92.doc - the issues we didn't get to address [replies to Bob Herriot and Hiroyuki Sato] Date: Mon, 25 Nov 1996 15:41:43 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Hi! >Here is a combined reply to Bob Herriot and Hiroyuki Sato on my original >comments. >Tom >>Is 'mail://' defined in some rfc? >Hiroyuki Sato wrote: >>If 'mail' means smtp, 'mailto' is a right one. >>More precise definition is 'mailto:End-User-Address@domain'. >What rfc should we cite? Please refer to RFC1738. Hiroyuki Sato Canon From ipp-archive Mon Nov 25 07:48:00 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA13940 for ipp-outgoing; Mon, 25 Nov 1996 07:45:06 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245423000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002245423000002*@MHS> To: Subject: IPP> Re: deBry security proposal Date: Mon, 25 Nov 1996 07:44:45 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: I read 1945 as authorization it NOT typically included, but sent only when requested by the server. However, I agree that the specification leaves soem room for interpretation. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 11/25/96 05:32 AM --------------------------- ipp-owner @ pwg.org 11/23/96 12:31 AM To: ipp @ pwg.org@internet cc: Subject: Re: deBry security proposal I would like to know if Authorization is typically included with an HTTP message or only if a server requests it. RFC 1945 is unclear on this point. I ask this because I would like one form of security to be where the client (not the end-user) automatically sends an attribute at the HTTP level with the user's name and ideally the domain name as well. Such values could implement the attributes operation-user-name and operation-host-name. This mechanism would allow a lightweight security mechanism that would work in cooperative environments where people don't want to deal with passwords but also don't want to cancel other people's jobs accidentally. I think that this is one case that Roger missed in his enumeration of possible security mechanisms. Bob Herriot From ipp-archive Mon Nov 25 07:53:00 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id HAA14115 for ipp-outgoing; Mon, 25 Nov 1996 07:51:31 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245504000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002245504000002*@MHS> To: Subject: IPP> Re: New Internet-Draft Request (another idea on the protocol Date: Mon, 25 Nov 1996 07:51:11 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Bob, I am not familiar enough with the real operation of HTTP protocols to know whether your idea is a good one or not. I had thought that I could only send one enitity at a time, which would require leaving the connection open and turning the line around several times to complete transfer of the message when sending the document along with the print request. How would this affect performance? Obviously this is not a concern when pulling the document later. What are the advantages of allowing "any" software to read the document data? Since I only apply the headers when sending the document to be printed I'm not sure what I gain? In my proposal, the document content itself still has a standard Mime type. ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 11/25/96 05:44 AM --------------------------- ipp-owner @ pwg.org 11/23/96 12:03 AM To: Scott_Isaacson @ novell.com@internet cc: ipp @ pwg.org@internet Subject: Re: New Internet-Draft Request (another idea on the protocol After thinking about the protocol issue some more, it seems like there are two ways to organize the IPP Job Object in HTTP Protocol, the current proposal or my proposal described below. 1) current proposal: The way proposed in the current document where the job and all document data is a part of a HTTP single entity-body. 2) my proposal: A job is an HTTP document whose top level content type is multipart/mixed (an existing type) or perhaps multipart/ipp (a new type and probably a bad idea). In either case, the first entity has a content type of application/ippjob and contains the job attributes. Each remaining entity contains a document and they are all standard MIME types, such as application/PostScript or text/plain. Such a document could in the future become a multipart/ippdocument with a document attribute entity and a document content entity if a document has attribute overrides. The document data entity could also have a content-type of multipart/alternative (an existing type) if a client wanted to have several representations of a document, e.g. HTTP and PDF and a printer supported such. The advantage of my proposal is that the document parts are conventional MIME documents which any software could read. Only the application/ippjob and application/ippdocument require special software to process. I hope others will comment on the pros and cons of these two proposals? Bob Herriot From ipp-archive Mon Nov 25 08:43:02 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id IAA14326 for ipp-outgoing; Mon, 25 Nov 1996 08:41:27 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002246044000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002246044000002*@MHS> To: <"ipp@PWG.ORG"@??.ibm.com> Subject: IPP> Question on directory schema attributes Date: Mon, 25 Nov 1996 08:41:07 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Scott, are the attributes described in section 4.2.x attributes in the same sense as those defined elswhere in the document? From ipp-archive Mon Nov 25 09:13:01 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14542 for ipp-outgoing; Mon, 25 Nov 1996 09:10:39 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002246379000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002246379000002*@MHS> To: Subject: IPP> Attribute syntax Date: Mon, 25 Nov 1996 09:10:19 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: In section 6.1, there seems to be a typo in the second line of type2Enum, which currently reads "add new TBDby proposing ...". Shoudn't this read "add new names by proposing ..."? Although the wording is slightly different, I could not distinguish a functional difference between type2Enum and type3Enum. Maybe I'm just a slow reader, but it appears that we could make a stronger distinction. From ipp-archive Mon Nov 25 10:03:01 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14740 for ipp-outgoing; Mon, 25 Nov 1996 10:02:25 -0500 (EST) Message-Id: Date: Mon, 25 Nov 96 10:03 EST From: jkm@underscore.com (JK Martin) To: robert.herriot@Eng.Sun.COM Subject: IPP> Re: New Internet-Draft Request (another idea on the protocol) Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Bob, I like your proposal a lot. It seems to draw well upon the original multi-part nature of MIME. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Mon Nov 25 10:18:01 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA14920 for ipp-outgoing; Mon, 25 Nov 1996 10:13:08 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002247146000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002247146000002*@MHS> To: Cc: Subject: IPP> job attributes et by Printer Date: Mon, 25 Nov 1996 10:12:48 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: Bob, can you explain the rationale behind setting job information attributes such as notification address in the Printer, thus requiring a separate set of operation attributes to be defined to set them? I find this confusing. If the intent is that the client and not the end-user sets these attributes, can't this be taken care of in the implementation of the client code? From ipp-archive Mon Nov 25 10:28:02 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA15086 for ipp-outgoing; Mon, 25 Nov 1996 10:27:14 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002247230000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002247230000002*@MHS> To: Subject: IPP> job-message-from-administrator attribute (section 6.2.3.4) Date: Mon, 25 Nov 1996 10:26:50 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Classification: Prologue: Epilogue: >From the description, it sounds like the name of this attribute should be "job-message-from-operator". From ipp-archive Mon Nov 25 12:48:04 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15394 for ipp-outgoing; Mon, 25 Nov 1996 12:46:14 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 25 Nov 1996 10:45:25 -0700 From: "Scott A. Isaacson" To: ipp@PWG.ORG, rdebry@us1.ibm.com Subject: IPP> Question on directory schema attributes -Reply Sender: ipp-owner@PWG.ORG Precedence: first-class Status: RO Roger, In this latest version that I am fixing up to submit to the IETF, Tom has done some great work to clarify this confusion. Look for it in the final document and if there are still some issues we can work them along with the many issues that we still have to work. Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ >>> 11/25/96 06:41am >>> Classification: Prologue: Epilogue: Scott, are the attributes described in section 4.2.x attributes in the same sense as those defined elswhere in the document? From ipp-archive Mon Nov 25 13:06:50 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA15619 for ipp-outgoing; Mon, 25 Nov 1996 12:58:47 -0500 (EST) Message-Id: <199611251759.AA11016@interlock.lexmark.com> To: "pwg%pwg.org" , "ipp%pwg.org" , P1284_3 From: Don Wright Date: 25 Nov 96 12:58:16 EST Subject: IPP> Albuquerque Meeting Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Just a reminder, a minor change, and a request: 1) Please, please, please make your reservations now! 2) The order of the PWG meetings has been changed due to several conflicts. (IPP now on Thursday, JMP/Sense now on Wednesday; PMP remains on Friday.) 3) I will be requesting a ping later in December. Please don't send it now as I tied up with the 1394 meeting. Thanks! Don -------------------------------------------------------- Here are the meeting details for the Jan meetings in Albuquerque: Where: Albuquerque Marriott 2101 Louisiana Blvd Albuquerque, NM 87110 505-881-6800 When: Jan 6-10, 1997 Price: $99 Deadline: Dec 27, 1996 Schedule: Jan 6 1284.4 Jan 7 1284.4 Jan 8 1284.3 PWG - JMP, Sense Jan 9 1284.3 PWG - IPP Jan 10 PWG - PMP ----------------------------- ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Nov 25 13:35:24 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA16108 for ipp-outgoing; Mon, 25 Nov 1996 13:29:43 -0500 (EST) Message-Id: <199611251830.AA12070@interlock.lexmark.com> To: "ipp%pwg.org" , "pwg%pwg.org" , P1284_3 From: Don Wright Date: 25 Nov 96 13:29:07 EST Subject: IPP> Albuerque Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I forgot to mention in my last note to ask for the Lexmark rate to get the $99 price. Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Mon Nov 25 15:13:03 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA16631 for ipp-outgoing; Mon, 25 Nov 1996 15:12:59 -0500 (EST) From: rdebry@us1.ibm.com X400-Originator: rdebry@us1.ibm.com X400-Recipients: ipp@pwg.org X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002252180000002] X400-Content-Type: P2-1988 (22) Message-Id: <5030100002252180000002*@MHS> To: Subject: IPP> Attribute Summary Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5030100002252180" Date: Mon, 25 Nov 1996 15:12:36 -0500 Sender: ipp-owner@pwg.org Precedence: first-class Status: RO --Boundary=_0.0_=5030100002252180 Classification: Prologue: Epilogue: I have generated a table that summarizes the use of all of the attributes in the current document IPP93). This was an enlightening exercise for me. It helped me to get my arms around all of the attribute discussion. I am attaching the WORD document for anyone who might find it useful. Would this be helpful as an appendix to the document? During this exercise, I came up with a number of questions and comments that ought to be folded into a subsequent version of the document: There are lots of client set attributes for which no default action is described if the attribute is not specified. Many of these are probably obvious, but ought to be written down for completeness. For example, job-notification, job-retention-period, medium select, sides, printer-resolution-select, and most of the "transformation" attributes. Defining the document content as a doucment attribute seems "strange" to me. Section 5.1 describes a quite different method for carrying the document content. These need to be reconciled. I'd recommend taking document-content out as an attribute. Do we need to define what happens when a client specifies a production attribute that is not supported? Should the client code prohibit this from happening some way? If it does, is this a "bug" in the client"? I'm don't undestand the need for operation-attributes. The text seems to suggest that these are used by the client to set attributes such as job-originator, so that the end-user doesn't deal with these directly (for ease of use or to prevent forgery). Why isn't this simply a matter of how the client code is implemented? For example, if the end-user uses an id and password to log onto the client, can't the client just pass these values along to the Printer in the orginal print request? Why must they appear in a different attribute? This only seems to complicate the oepration. The 4th paragraph of section 6.2.7 (Job Production Attributes) needs some editorial work. There appear to be some incomplete or run-on sentences. In section 6.2.8.3, is the length of the media in lines rather than characters? This would be consistent with top and bottom margin. In this entire section on conversion attributes, we need to be crisp on the use of document versus job. I think that in the current version of the draft, these should all apply to a job, not a document as the drfat is currently written. Otherwise should they be document attributes? In section 6.2.8.11, it looks like default-font needs its own section heading. It seems to me that job resource attributes are VERY optional since their appearance depends upon major changes to things like device drivers. If we are going to suggest that device drivers be changed to generate these attributes wouldn't we'd be better off asking device drivers to generate real IPP attributes instead. For example, why ask a Postscript driver to change to add a "media-used" attribute instead of asking it to generate the medium-select attribute. I'm also concerned that we might expect intermediate software to scan a PDL to locate all of the resources to be used - this seems an onerous task. I don't understand the use of job-intervening-jobs. Since this is a Job Resources attribute and is supposedly set by a driver , what does it mean? What does it mean if set by the client? Is it out of place? The header for Section 6.4 suggests that all of these attributes are set by an adminstrator. Is this true? Why wouldn't we expect some to be set by the Printer using SNMP to get the values from the Printer MIB? Why require an adminstrator to be put into teh middle where one is not required. Of course an administratot may set policy attributes, such as maximum number of copies or job size. Should these be defined as a seprate category of administrative or policy attributes? Since all of the Printer atributes might reflect a collection of printers supported by a server, shouldn't all of the attributes in this section be multi-valued. For example, should printer-name be #1string, suggesting that all of the printer names would be returned if multiple printers were supported? In this section we sometimes use printer (lower-case) and sometimes Printer(upper-case). We should crisp this up. Does printer (lower-case) really mean output device? I don't understand section 6.4.10, notification-address. What does it mean for this to be a printer attribute, given that this value is sent to the Printer as a job attribute? Similarly, what is the meaning of notification-events as a printer attribute, given that it is sent to the Printer as a job attribute? Following is my summary table... Have a nice Thanksgiving everyone, see you in San Jose! --Boundary=_0.0_=5030100002252180 Content-Type: application/octet-stream; name="IPP Attributes.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAABAAAAAAAAAAA EAAAEgAAAAEAAAD+////AAAAAAUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9S AG8AbwB0ACAARQBuAHQAcgB5AAAAAAB/CAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAgA AACKAQAAFgAFAf//////////AQAAAAAJAgAAAAAAwAAAAAAAAEYAAAAAIES1cazYuwHwc/uTBdu7 AQMAAACAAwAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAKg3FAAA AAAAAAAAAAAAAAAJAAAAOwAAAKFlAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAP// //+WAAAAkQUAAAAAAAAAAAAALAEAAIwKAADILxQA//8AABIAAgH///////////////8AAAAAAAAA AAAAAAAAAAAAADAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAACAAAAIoBAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////8E AAAA/////wMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADIAQAAAAAAABQA AAD9/////v///wIAAAD///////////////////////////////8LAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEwAAAP7///8cAAAA/v////////////////////////////////////////8sAAAA //////////////////////////////////////////////////////////////////////////// ////LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAD+////PAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAA AEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAAoAAAD///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////KAAA AEAAAAAA9JvI/9q7AUAAAAAAkJxjrNi7AUAAAAAAKuKCBdu7AQMAAAAGAAAAAwAAADsFAAADAAAA 1R0AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAA AACsAAAACAAAAAEAAABIAAAADwAAAFAAAAAEAAAAXAAAAAUAAABkAAAABgAAAGwAAAALAAAAdAAA ABAAAAB8AAAADAAAAIQAAAACAAAA5AQAAB4AAAAEAAAAaWJtAAMAAAAArAAAAwAAAD8AAAADAAAA DwAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAAAB4AAAAPAAAASm9iIEF0dHJpYnV0ZXMAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/ AwoAAP////8ACQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABN U1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuNgD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA AJgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAC4AAAABAAAAMQAAAAFAAAA2AAAAAYAAADkAAAA BwAAAPAAAAAIAAAAAAEAAAkAAAAUAQAAEgAAACABAAAKAAAASAEAAAsAAABUAQAADAAAAGABAAAN AAAAbAEAAA4AAAB4AQAADwAAAIABAAAQAAAAiAEAABMAAACQAQAAAgAAAOQEAAAeAAAADwAAAEpv YiBBdHRyaWJ1dGVzAAAeAAAAAQAAAAAAAAAeAAAADAAAAHJvZ2VyIGRlYnJ5AB4AAAABAAAAAAAA AB4AAAABAAAAAAAAAB4AAAAHAAAATm9ybWFsAAAeAAAADAAAAHJvZ2VyIGRlYnJ5AB4AAAACAAAA NgAAAB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFdpbmRvd3MgOTUAAABAAAAAAMCuO1IAbwBv AHQAIABFAG4AdAByAHkAAAAAAH8IAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAACAAAAIoB AAAWAAUB//////////8BAAAAAAkCAAAAAADAAAAAAAAARgAAAAAgRLVxrNi7AYCJMpQF27sBAwAA AIADAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAqDcUAAAAAAAA AAAAAAAAAAkAAAAGAAAAoWUAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA/////5YA AACRBQAAAAAAAAAAAAAsAQAAjAoAAMgvFAD//wAAEgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAMAQAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAIAAAAigEAAAAAAAAAAAAAAAAAAAAAAAAoAAIB/////wQAAAD/ ////AwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAMgBAAAAAAAA//////// ///+////AgAAABQAAAD9////BwAAAAgAAAAJAAAAFQAAAP////////////////////////////// /////////////v/////////+////FgAAABcAAAAYAAAAQwAAABoAAAAbAAAAHQAAAP////8eAAAA HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAAFUAAAD/ //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////0QAAABFAAAARgAAAEcAAABIAAAASQAA AEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAABkAAAD//////////1YAAABXAAAA WAAAAFkAAABaAAAAWwAAAFwAAABdAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////cpWgAY+AJ BAAAJABlAAAAAAAAAAAAAAAAAwAAfRAAAKFlAAAAAAAAAAAAAAAAAAAAAAAALiQAAAoFAADpAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAPAAAAAAGgAA8AAAAABGAABGAAAARkYAADQAAADg RgAAAAAAAOBGAAAAAAAA4EYAACQAAABoTQAAAAAAAGpHAAD+BQAAaE0AAAAAAABoTQAAAAAAAGhN AAAQAAAAeE0AACIAAACaTQAAKAAAAGhNAAAAAAAA4GQAADEAAADCTQAAAAAAAMJNAAAAAAAAwk0A AAAAAADCTQAAAAAAAMJNAAAAAAAAwk0AAAAAAADCTQAAAAAAAMJNAAAAAAAAok8AAAIAAACkTwAA AAAAAKRPAAAAAAAApE8AACUAAADJTwAADAEAANVQAAAMAQAA4VEAAB4AAAARZQAAWAAAAGllAAA4 AAAA/1EAAOESAAAAAAAAAAAAAAAAAAAAAAAA4EYAAAAAAADCTQAAAAAAAAAACQAKAAUABgDCTQAA AAAAAMJNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJNAAAAAAAAwk0AAAAAAAD/UQAAAAAAAFhPAAAA AAAA4EYAAAAAAADgRgAAAAAAAMJNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMJNAAAAAAAAWE8AAAAA AABYTwAAAAAAAFhPAAAAAAAAwk0AAJYBAADgRgAAAAAAAMJNAAAAAAAA4EYAAAAAAADCTQAAAAAA AKJPAAAAAAAAAAAAAAAAAADgAjGUBdu7AQRHAAAmAAAAKkcAAEAAAAB6RgAAJgAAAKBGAABAAAAA 4EYAAAAAAADgRgAAAAAAAMJNAAAAAAAAok8AAAAAAABYTwAASgAAAFhPAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABJUFAgQXR0cmlidXRlIFN1bW1hcnkNDVRoZSBmb2xsb3dpbmcg dGFibGUgc3VtbWFyaXplcyB0aGUgYXR0cmlidXRlcyBkZWZpbmVkIGluIHRoZSBJUFAgc3BlY2lm aWNhdGlvbi4gIFRoZSBjb2x1bW5zIGluIHRoZSB0YWJsZSBoYXZlIHRoZSBmb2xsb3dpbmcgbWVh bmluZzoNDUNsaWVudCB2aWV3OiBUaGUgY2xpZW50IG1heSBnZW5lcmF0ZSBhIHJlcXVlc3QgdG8g Z2V0IHRoZSB2YWx1ZSBvZiB0aGlzIGF0dHJpYnV0ZS4gIEEgk3mUIGluIHRoaXMgY29sdW1uIGlu ZGljYXRlcyB0aGF0IHRoZSBjbGllbnQgbXVzdCBhY2NlcHQgdGhlIGF0dHJpYnV0ZSBhbmQgaXRz IGNvcnJlc3BvbmRpbmcgdmFsdWUgaW4gYSByZXNwb25zZS4gIElmIG9yIGhvdyBhIGNsaWVudCBw cmVzZW50cyB0aGlzIGluZm9ybWF0aW9uIHRvIGFuIGVuZC11c2VyIGlzIGltcGxlbWVudGF0aW9u IGRlZmluZWQuDQ1DbGllbnQgZ2VuZXJhdGU6IEEgk3mUIGluIHRoaXMgY29sdW1uIGluZGljYXRl cyB0aGF0IHRoZSBjbGllbnQgbXVzdCBnZW5lcmF0ZSBhIHZhbGlkIHZhbHVlIGZvciB0aGlzIGF0 dHJpYnV0ZSB3aGVuIHN1Ym1pdHRpbmcgYSBQcmludCBPcGVyYXRpb24uIEFuIJNulCBpbmRpY2F0 ZXMgdGhhdCBhIGNsaWVudCBtdXN0IG5vdCBnZW5lcmF0ZSB0aGlzIGF0dHJpYnV0ZSwgYW4gk2+U IGluZGljYXRlcyB0aGF0IGl0IGlzIG9wdGlvbmFsLg0NUHJpbnRlciBhY2NlcHQ6IFRoZSBQcmlu dGVyIG9iamVjdCBtdXN0IGFjY2VwdCB0aGlzIGF0dHJpYnV0ZSBhbmQgdXNlIHRoZSBjb3JyZXNw b25kaW5nIGF0dHJpYnV0ZSB2YWx1ZSBpbiB0aGUgSVBQIG9wZXJhdGlvbiBzcGVjaWZpZWQsIGFz IGRlZmluZWQgaW4gdGhlIElQUCBSRkMuDQ1QcmludGVyIGdlbmVyYXRlOiBBIJNZlCBpbiB0aGlz IGNvbHVtbiBpbmRpY2F0ZXMgdGhhdCB0aGUgUHJpbnRlciBvYmplY3QgbXVzdCBnZW5lcmF0ZSB2 YWxpZCB2YWx1ZXMgZm9yIHRoaXMgYXR0cmlidXRlIHdoZW4gcmVxdWVzdGVkIGZyb20gdGhlIGNs aWVudC4gk05vbmWUIGlzIGFuIGFjY2VwdGFibGUgdmFsdWUgd2hlbiBhbiBhdHRyaWJ1dGUgaXMg bm90IHN1cHBvcnRlZCBieSBhIHBhcnRpY3VsYXIgZGV2aWNlLg0NU3ludGF4OiBUaGUgc3ludGF4 IG9mIHRoZSBhdHRyaWJ1dGUgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNi4xIG9mIHRoZSBSRkMu DQ1TL006ICBUaGUgYXR0cmlidXRlIGlzIHNpbmdsZSBvciBtdWx0aXBsZSB2YWx1ZWQuDQ1Db21t ZW50OiAgU2hvcnQgZGVzY3JpcHRpb24gb2YgdGhlIHNlbWFudGljIG9mIHRoaWVzZSBhdHRyaWJ1 dGVzIG92ZXIgdGhvc2UgZGVmaW5lZCBpbiB0aGUgUERMIGlzIGltcGxlbWVudGF0aW9uIGRlZmlu ZWQuIEFsbCBkZXZpY2VzIHdpbGwsIG5vdCBzdXBwb3J0IGFsbCBwcm9kdWN0aW9uIGF0dHJpYnV0 ZXMuDQIgVGhlc2UgYXR0cmlidXRlcyBhaWQgaW4gdGhlIGZvcm1hdHRpbmcgb2YgdGV4dCBkb2N1 bWVudHMgdGhhdCBkbyBub3QgY29udGFpbiBmb3JtYXR0aW5nIGluZm9ybWF0aW9uLg0CIFRoZXNl IGF0dHJpYnV0ZXMgYXJlIHNldCBieSB0aGUgcHJvZ3JhbSB0aGF0IGdlbmVyYXRlcyBvciBzZW5z ZXMgdGhlIFBETCB0byBhbGVydCB0aGUgUHJpbnRlciB0byByZXNvdXJjZXMgcmVxdWlyZWQgdG8g cHJpbnQgdGhlIGpvYi4gVGhlc2UgYXR0cmlidXRlcyBtYXkgdGhlbiBiZSB1c2VkIGluIHZhbGlk YXRpbmcgYW5kIHNjaGVkdWxpbmcgdGhlIHByaW50IGpvYi4gDQIgVGhpcyAgVVJMIHdpbGwgYmUg dXNlZCB0byBmZXRjaCB0aGUgZG9jdW1lbnQgd2hlbiBpdCBpcyBub3QgaW5jbHVkZWQgaW4gdGhl IHByaW50IG9wZXJhdGlvbi4NAiBJZiBhIFByaW50ZXIgZG9lcyBub3Qgc3VwcG9ydCBhIGZlYXR1 cmUsIGUuZy4gb2ZmLXBlYWstdGltZXMtc3VwcG9ydGVkLCB0aGVuIGl0IHdpbGwgcmV0dXJuIJNu b25llCBmb3IgdGhlIHZhbHVlIG9mIHRoZSBhdHRyaWJ1dGUgd2hlbiByZXF1ZXN0ZWQuDRwAmQKi AqTgPaXQL6agBaegBagIB6kIB6oAAKsBAB4AjwGZEKICpOA9pdAvpqAFp6AFqAgHqQgHqgAAqwEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjEQAAKhEAACsRAAA5 EQAAOhEAAD0RAABIEQAASxEAAEwRAABQEQAAUhEAAFMRAABUEQAAWBEAAGARAAB9EQAAfhEAAH8R AACHEQAAiBEAAJcRAACaEQAAmxEAAKERAACjEQAApBEAAKURAACmEQAApxEAAKgRAAC1EQAAtxEA ALgRAAC6EQAAuxEAALwRAAC9EQAAvxEAAMERAADCEQAAwxEAAMQRAADGEQAAxxEAAMgRAADJEQAA yxEAAMwRAADNEQAAzhEAAM8RAADREQAA0hEAANMRAADVEQAA1hEAANcRAADYEQAA5xEAAP0RAADw GgAA8RoAAAYbAAAHGwAAChsAAAsbAAAXGwAAIhsAACUbAAAmGwAAUhsAAGMbAABkGwAAZxsAAGgb AAB1GwAAjxsAAJQbAACZGwAArBsAAK4bAADHGwAAyBsAAMkbAADeGwAAExwAACkcAAAuHAAALxwA ADUcAABYHAAAeRwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP39/f39/f39/f39/f39/f39/f39 /f39/fX9/f39/f39/fLy8PL9/f39/f39/f39/f39/f39/f398ufy/f39/f39/f0AAAAQdQFEBAAA AABQEgBVgV0CAAACdQEABVWBXQIADnUBRAQAAAAAUBIAXQIAAANdAgAAW3kcAACjHAAAphwAAKcc AACvHAAADh0AABMdAAAdHQAAWR0AAH4dAAChHQAArh0AALUdAAC9HQAAwB0AAMQdAADQHQAA+R0A AP4dAAARHgAAuB4AAN8eAADgHgAA4R4AAGsfAACxHwAA1h8AAPYfAACuIAAAtCAAAPIgAAD4IAAA PCEAAM0hAADZIQAA4SEAAIIiAACDIgAAhCIAAIYiAACZIgAAmiIAAJsiAABHJAAAnSQAAG0lAABw JQAAcSUAAIQlAACFJQAAlSUAAJYlAAA0JgAAhSYAAJkmAAC1JgAA5yYAAPomAAD7JgAAKCcAACsn AAAsJwAAWScAAFwnAABdJwAAZScAAGYnAACZJwAAnCcAAJ0nAACnJwAAuycAALwnAADaJwAA2ycA AO4nAADxJwAA8icAAPwnAAD/JwAAACgAAC4oAABrKAAAbygAAHUoAACcKAAAnygAAKAoAAANKQAA HykAACApAAAhKQAAgCkAAP39/f39/f39/f39/f39/f39/f39+vH9/f39/f39/f39/f39/fr6+vrx +v39/f39/f39/f39+v39+vr9/f39/f396f39/f36/f39/f39/f39/f39/f39/f368fr9AAAOdQFE BAAAAABQEgBdAgAAEHUBRAQAAAAAUBIAVYFdAgAABVWBXQIAA10CAABcgCkAAIYpAADHKQAA3ykA AOgpAAD+KQAAICoAAEwqAABNKgAAZSoAAHAqAABzKgAAdCoAAKMqAADPKgAA1yoAAP0rAAAMLAAA HywAACIsAAArLAAAMCwAADIsAABiLAAA0SwAAFYtAABXLQAAWC0AAGstAABvLQAAcC0AAL0tAADH LQAA3S0AAAwuAAAPLgAAEC4AAF4uAABhLgAAYi4AALkuAAC8LgAAvS4AAA8vAAASLwAAEy8AACkv AAAKMAAAFDAAABUwAAAkMAAAMTAAADwwAAA/MAAAQDAAAKIwAADQMAAA0TAAANMwAADuMAAA7zAA APkwAADoMQAAKDIAALMyAAC6MgAAzzIAABUzAAAWMwAAFzMAABgzAAAZMwAAGjMAABszAAAcMwAA HTMAAB4zAAAlMwAAJzMAAD4zAAA/MwAARDMAAEozAABMMwAAaTMAAGozAACMMwAAjzMAAJAzAACg MwAAozMAAKQzAACqMwAAsjMAALMzAAC0MwAAtTMAAL8zAADDMwAA/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f0A AAAAAAAAAAAA9wAAAAAAAAAAAAD3AAALdQFEBAAAAABQEgADXQIAAGLDMwAAxDMAANwzAADfMwAA 4DMAACk0AAAsNAAARzQAAIA0AACBNAAAgjQAAIQ0AACFNAAAiTQAAOc0AADoNAAA6TQAAG41AABx NQAAcjUAAHY1AACvNQAAsjUAALM1AAC9NQAAvjUAAL81AADANQAA4TUAAOQ1AADlNQAACTYAAAw2 AAANNgAAHTYAAB42AAAfNgAAWzYAAGY2AAB8NgAAgTYAALE2AACyNgAA8DYAAAAAAAAAAAAAAPkA AAAAAPkAAAAAAAAAAAAA+QAAAAAAAAAA+QAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQALdQFEBAAAAABQEgAAK9EdAAASHgAAah4AALceAAC4 HgAA4R4AABQfAABEHwAAiR8AANAfAAAOIAAAUSAAAJogAADeIAAAIiEAAGYhAACbIQAA4iEAADQi AACBIgAAgiIAAJsiAAD1IgAARiMAAJUjAADkIwAANSQAAI8kAADZJAAANCUAAH8lAADVJQAANCYA AIQmAACFJgAAmSYAAOYmAADnJgAA+yYAADUnAABnJwAApicAAKcnAAC8JwAA8QABoDLmAPEAAaAy 5gDxAAGgMuYA8QABoDLmAPEAAaAy8ADxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLm APEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA 8QABoDLmAPEAAaAy5gDxAAGgMvAA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDx AAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEA AaAy8ADxAAGgMuYA8QABoDLmAPEAAaAy8ADxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QAB oDLwAAAAAAAADgAADxcAB/sLEA6bEbATgBYgHPAeAQEBAQAAAAArvCcAAAcoAABhKAAAsigAAAgp AAAJKQAACikAAAspAAAMKQAADSkAACEpAABnKQAAsSkAAP4pAABFKgAAfCoAANAqAAD6KgAAPCsA AJIrAADfKwAAMiwAAH8sAADRLAAAKC0AAIUtAADeLQAAKy4AAIEuAADRLgAAKS8AAHMvAADHLwAA CzAAAFIwAACjMAAA+jAAAEIxAACQMQAA2jEAACQyAAB5MgAA0DIAABYzAADxAAGgMuYA8QABoDLm APEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMvAA 8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDx AAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEA AaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QAB oDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGg MuYAAAAAAAAOAAAPFwAH+wsQDpsRsBOAFiAc8B4BAQEBAAAAACsBAAAA/v///wMAAAAEAAAABQAA AAYAAAAHAAAACAAAAAkAAAD+////CwAAAAwAAAANAAAA/v////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////xYzAAAXMwAAGjMAABwzAAAdMwAA tDMAAIE0AADoNAAAvzUAAB42AACyNgAA8QABoDLmAPEAAaAy5gDxAAGgMuYA7wAAAAAAAO0AAAAA AADtAAAAAAAA7QAAAAAAAO0AAAAAAADtAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAER AAABAAAADgAADxcAB/sLEA6bEbATgBYgHPAeAQEBAQAAAAAKBQBEAG8AYwB1AG0AZQBuAHQAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAA3AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzIGF0dHJpYnV0ZS4NDUZvb3Rub3Rl cyBkZXNjcmliZSBhbm9tYWxpZXMgb3Igc3BlY2lhbCBjYXNlcy4NDQxKb2IgQXR0cmlidXRlcw1q b2ItbmFtZQl5CW8CCXkJbglzdHJpbmcJcwlodW1hbiByZWFkYWJsZSBzdHJpbmcgbmFtaW5nIHRo ZSBqb2INam9iLWlkZW50aWZpZXIJeQluCW4CCXkJc3RyaW5nCXMJdXJsIG9mIHRoaXMgam9iLCB0 byBiZSB1c2VkIGZvciBzdWJzZXF1ZW50IG9wZXJhdGlvbnMNam9iLW9yaWdpbmF0b3IJeQluCW4J eQlzdHJpbmcJcwltb3N0IGF1dGhlbnRpY2F0ZWQgdXNlciBuYW1lIG9idGFpbmVkIGZyb20gY2xp ZW50DWpvYi1vcmlnaW5hdGluZy1ob3N0CXkJbgluCXkJc3RyaW5nCXMJbW9zdCBhdXRoZW50aWNh dGVkIGhvc3QgbmFtZSBvYnRhaW5lZCBmcm9tIGNsaWVudA1ub3RpZmljYXRpb24tYWRkcmVzcwl5 CW4Jbgl5CXN0cmluZwlzCWN1cnJlbnRseSB0aGUgZW1haWwgYWRkcmVzcyBmb3Igbm90aWZpY2F0 aW9uIG9mIGV2ZW50cw1qb2ItbG9jYWxlCXkJbgluCXkJdHlwZTNMb2NhbGUJcwlsb2NhbGUgdG8g YmUgdXNlZCBpbiBhbGwgZXZlbnQgbm90aWZpY2F0aW9ucw0NSm9iIFN0YXR1cyBBdHRyaWJ1dGVz DWN1cnJlbnQtam9iLXN0YXRlCXkJbgluCXkJdHlwZTFlbnVtCXMJc3RhdGUgb2YgdGhlIHByaW50 IGpvYiBpbiB0aGUgUHJpbnRlcg1vdXRwdXQtZGV2aWNlLWFzc2lnbmVkCXkJbgluCW8CCXN0cmlu ZwlzCW5hbWUgb2Ygb3V0cHV0IGRldmljZSBhc3NpZ25lZCBieSB0aGUgUHJpbnRlcg1zdWJtaXNz aW9uLXRpbWUJeQluCW4JbwlkYXRlL3RpbWUJCXRpbWUgUHJpbnQgam9iIHdhcyBhY2NlcHRlZA1q b2ItbWVzc2FnZS1mcm9tLW9wZXJhdG9yCXkJbgluCXkJc3RyaW5nCW1lc3NhZ2UgZnJvbSBQcmlu dGVyIJNvcGVyYXRvcpQNY29tcGxldGlvbi10aW1lCXkJbgluCW8JZGF0ZS90aW1lCXRpbWUgcHJp bnQgam9iIGNvbXBsZXRlZA1qb2Itc3RhdGUtcmVhc29ucwl5CW4Jbgl5CXR5cGUgMiBlbnVtCXJl YXNvbiBmb3IgY3VycmVudCBqb2Igc3RhdGUgaW4gUHJpbnRlcg1pbXByZXNzaW9ucyBjb21wbGV0 ZWQJeQluCW4JbwIJY2FyZGluYWwJbnVtYmVyIG9mIGltcHJlc3Npb25zIFByaW50ZXIgaGFzIHBy aW50ZWQNbWVkaWEtc2hlZXRzLWNvbXBsZXRlZAl5CW4JbglvAgljYXJkaW5hbAludW1iZXIgb2Yg c2hlZXRzIFByaW50ZXIgaGFzIHByaW50ZWQNDUpvYiBTaGVldCBBdHRyaWJ1dGVzDWpvYi1zaGVl dHMJeQl5CXkJbgl0eXBlIDMgZW51bQljb250cm9scyBwcmludGluZyBvZiBqb2Igc2hlZXRzDQ1O b3RpZmljYXRpb24gQXR0cmlidXRlcw0Nbm90aWZpY2F0aW9uIGV2ZW50cwl5CXkJeQluCXR5cGUg MSBlbnVtCWV2ZW50cyBjbGllbnQgd2FudHMgdG8gYmUgbm90aWZpZWQgZm9yDUpvYiBTY2hlZHVs aW5nIEF0dHJpYnV0ZXMNam9iLXByaW9yaXR5CXkJeQl5CW4JdHlwZSAyIGVudW0JdXNlZCBpbiBz Y2hlZHVsaW5nIHRoZSBqb2INam9iLXByaW50LWFmdGVyCXkJeQl5CW4JZGF0ZS90aW1lCXByaW50 IGFmdGVyIHRoZSBzcGVjaWZpZWQgZGF0ZSBhbmQgdGltZQkJCQ0NDQ0CIElmIG5vdCBzcGVjaWZp ZWQsIHRoZSBQcmludGVyIHdpbGwgdXNlIHRoZSBmaWxlIG5hbWUgb2YgdGhlIGZpcnN0IGRvY3Vt ZW50IGluIHRoZSBQcmludCBqb2IuDQ0CIFByaW50ZXIgb25seSBzZWVzIGpvYi1pZGVudGlmaWVy IGFzIHRoZSB0YXJnZXQgb2YgYSBVUkwsIG5ldmVyIGFzIGFuIGF0dHJpYnV0ZQ0NAiBPbmx5IHJl cXVpcmVkIHdoZW4gbXVsdGlwbGUgb3V0cHV0IGRldmljZXMgb3BlcmF0ZSB1bmRlciBhIHNpbmds ZSBQcmludGVyIG9iamVjdA0NAiBFdmVyeSBvdXRwdXQgZGV2aWNlIG1heSBub3QgYmUgY2FwYWJs ZSBvZiByZXBvcnRpbmcgdGhpcyB2YWx1ZQ0NAiBFdmVyeSBvdXRwdXQgZGV2aWNlIG1heSBub3Qg YmUgY2FwYWJsZSBvZiByZXBvcnRpbmcgdGhpcyB2YWx1ZQ0NDSANDUlQUCBBdHRyaWJ1dGUgU3Vt bWFyeQ0NQXR0cmlidXRlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2xp ZW50ICAgICAgICAgICAgICAgIFByaW50ZXIgICAgICBzdXBwb3J0ZWQNbG9jYWxlcy1zdXBwb3J0 ZWQJeQluCW4JeQkxI3R5cGUzTG9jYWxTCW0JYWxsIG9mIHRoZSBsb2NhbGVzIHN1cHBvcnRlZA1q b2Itc2hlZXRzLXN1cHBvcnRlZAl5CW4Jbgl5CSN0eXBlM0VudW1TCW0JYWxsIG9mIHRoZSBqb2Ig c2hlZXQgdmFsdWVzIHN1cHBvcnRlZA1tYXhpbXVtLWNvcGllcwl5CW4Jbgl5CXBvc2l0aXZlSW50 ZWdlcglzCW1heGltdW0gbnVtYmVyIG9mIGNvcGllcyB3aGljaCBjYW4gYmUgcHJpbnRlZA1tYXhp bXVtLWpvYi1vY3RldHMJeQluCW4JeQlwb3NpdGl2ZUludGVnZXIJcwltYXhpbXVtIGpvYiBzaXpl IGluIG9jdGV0cw1tYXhpbXVtLWltcHJlc3Npb25zCXkJbgluCXkJcG9zaXRpdmVJbnRlZ2VyCXMJ bWF4aW11bSBqb2Igc2l6ZSBpbiBpbXByZXNzaW9ucw1tYXhpbXVtLW1lZGlhLXNoZWV0cwl5CW4J bgl5CXBvc2l0aXZlSW50ZWdlcglzCW1heGltdW0gam9iIHNpemUgaW4gc2hlZXRzDW1heGltdW0t am9iLXJldGVudGlvbi1wZXJpb2QJeQluCW4JeQlkZWx0YVRpbWUJcwltYXhpbXVtIHJldGVudGlv biBwZXJpb2QNbWF4aW11bS1lbmQtdXNlci1wcmlvcml0eQl5CW4Jbgl5CXR5cGUxRW51bQlzCW1h eGltdW0gcHJpb3JpdHkgdGhhdCBjYW4gYmUgc3BlY2lmaWVkDXF1ZXVlZC1qb2ItY291bnQJeQlu CW4JeQlwb3NpdGl2ZUludGVnZXIJcwludW1iZXIgb2Ygam9icyBlaXRoZXIgcGVuZGluZyBvciBw cm9jZXNzaW5nDXNjaGVkdWxpbmctYWxnb3JpdGhtCXkJbgluCXkJdHlwZTNFbnVtCXMJY3VycmVu dCBzY2hlZHVsaW5nIGFsZ29yaXRobQ0NCQkNCQ0NIElmIHRoZSBpcyBpdCBzaG91bGQgcmVtYWlu IHVuc3BlY2lmaWVkSWYgdGhlaXMgaXQgc2hvdWxkIHJlbWFpbiB1bnNwZWNpZmllZAIgSWYgbm8g cHJpb3JpdHkgaXMgc3BlY2lmaWVkIHRoZW4gdGhlIFByaW50ZXIgYXNzaWducyB0aGUgdmFsdWUg k2RlZmF1bHSUDQIgUmVxdWVzdHMgc29tZSBmZWF0dXJlIG5vdCBpbWJlZGRlZCBpbiB0aGUgUERM IGl0c2VsZi4gVGhlIHByZWNlZGVuY2Ugb2YgdGhlc2UgYXR0cmlidXRlcyBvdmVyIHRob3NlIGRl ZmluZWQgaW4gdGhlIFBETCBpcyBpbXBsZW1lbnRhdGlvbiBkZWZpbmVkLiBBbGwgZGV2aWNlcyB3 aWxsLCBub3Qgc3VwcG9ydCBhbGwgcHJvZHVjdGlvbiBhdHRyaWJ1dGVzLg0CIFRoZXNlIGF0dHJp YnV0ZXMgYWlkIGluIHRoZSBmb3JtYXR0aW5nIG9mIHRleHQgZG9jdW1lbnRzIHRoYXQgZG8gbm90 IGNvbnRhaW4gZm9ybWF0dGluZyBpbmZvcm1hdGlvbi4NAiBUaGVzZSBhdHRyaWJ1dGVzIGFyZSBz ZXQgYnkgdGhlIHByb2dyYW0gdGhhdCBnZW5lcmF0ZXMgb3Igc2Vuc2VzIHRoZSBQREwgdG8gYWxl cnQgdGhlIFByaW50ZXIgdG8gcmVzb3VyY2VzIHJlcXVpcmVkIHRvIHByaW50IHRoZSBqb2IuIFRo ZXNlIGF0dHJpYnV0ZXMgbWF5IHRoZW4gYmUgdXNlZCBpbiB2YWxpZGF0aW5nIGFuZCBzY2hlZHVs aW5nIHRoZSBwcmludCBqb2IuIA0CIFRoaXMgIFVSTCB3aWxsIGJlIHVzZWQgdG8gZmV0Y2ggdGhl IGRvY3VtZW50IHdoZW4gaXQgaXMgbm90IGluYxcGAABfBgAAeAgAAOoJAAA/CgAAWwsAANQMAADs DwAAphMAAHIYAAAsGgAAAysAAAEAAgADAAQABQAGAAcACAAJAAoACwAAAAAAYAAAALEAAAAEAQAA YgEAAMABAAALAgAA2AIAAD8DAAAWBAAAdQQAAAkFAAAMBQAABgAQAf//AQAAAP//AgAAAP//AwAA AP//BAAAAP//BQAQAP//BgAAAAAAAAAAAAsCAAA/AwAAdQQAAAkFAAAMBQAAAAAAAAAAAQAAAAAA AgAAAAAAAwAAAAAABAAAAAAABQAAAAAAAAAAAPwFAAADKwAABACyNgAACAD/////BADQNgAACAD/ ////BgAEIf//AQAAIf//AgAEIP//AwAAIP//BAAEIP//BQACIP//BgAAAAAA/AUAANgLAACPEwAA GhoAACMkAAADKwAAAAAAAAAAAQDlAQAAAgBiAQAAAwA4AQAABAAGAAAABQAAAAAAAAAAABYAAAAX AAAAnQAAAJ4AAAC+AQAAvwEAACIDAAAjAwAAxgMAAMcDAAAKBQAACwUAAFcFAABYBQAAigUAAIsF AADKBQAAywUAAPwFAAALBgAASwYAAKIGAAD0BgAATAcAAKkHAAD3BwAA+AcAAA4IAABaCAAAsQgA APEIAABBCQAAfgkAAM0JAAAhCgAAcQoAAHIKbHVkZWQgaW4gdGhlIHByaW50IG9wZXJhdGlvbi4N AiBJZiBhIFByaW50ZXIgZG9lcyBub3Qgc3VwcG9ydCBhIGZlYXR1cmUsIGUuZy4gb2ZmLXBlYWst dGltZXMtc3VwcG9ydGVkLCB0aGVuIGl0IHdpbGwgcmV0dXJuIJNub25llCBmb3IgdGhlIHZhbHVl IG9mIHRoZSBhdHRyaWJ1dGUgd2hlbiByZXF1ZXN0ZWQuDRwAmQKiAqTgPaXQL6agBaegBagIB6kI B6oAAKsBAB4AjwGZEKICpOA9pdAvpqAFp6AFqAgHqQgHqgAAqwEADRwAmQKiAqTgPaXQL6agBaeg BagIB6kIB6oAAKsBAB4AjwGZEKICpOA9pdAvpqAFp6AFqAgHqQgHqgAAqwEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjEQAAKhEAACsRAAA5EQAAOhEAAD0RAABIEQAASxEA AEwRAABQEQAAUhEAAFMRAABUEQAAWBEAAGARAAB9EQAAfhEAAH8RAACHEQAAiBEAAJcRAACaEQAA mxEAAKERAACjEQAApBEAAKURAACmEQAApxEAAKgRAAC1EQAAtxEAALgRAAC6EQAAuxEAALwRAAC9 EQAAvxEAAMERAADCEQAAwxEAAMQRAADGEQAAxxEAAMgRAADJEQAAyxEAAMwRAADNEQAAzhEAAM8R AADREQAA0hEAANMRAADVEQAA1hEAANcRAADYEQAA5xEAAP0RAADwGgAA8RoAAAYbAAAHGwAAChsA AAsbAAAXGwAAIhsAACUbAAAmGwAAUhsAAGMbAABkGwAAZxsAAGgbAAB1GwAAjxsAAJQbAACZGwAA rBsAAK4bAADHGwAAyBsAAMkbAADeGwAAExwAACkcAAAuHAAALxwAADUcAABYHAAAeRwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP39/f39/f39/f39/f39/f39/f39/f39/fX9/f39/f39/fLy8PL9 /f39/f39/f39/f39/f39/f398ufy/f39/f39/f0AAAAQdQFEBAAAAABQEgBVgV0CAAACdQEABVWB XQIADnUBRAQAAAAAUBIAXQIAAANdAgAAW3kcAACjHAAAphwAAKccAACvHAAADh0AABMdAAAdHQAA WR0AAH4dAAChHQAArh0AALUdAAC9HQAAwB0AAMQdAADQHQAA+R0AAP4dAAARHgAAuB4AAN8eAADg HgAA4R4AAGsfAACxHwAA1h8AAPYfAACuIAAAtCAAAPIgAAD4IAAAPCEAAM0hAADZIQAA4SEAAIIi AACDIgAAhCIAAIYiAACZIgAAmiIAAJsiAABHJAAAnSQAAG0lAABwJQAAcSUAAIQlAACFJQAAlSUA AJYlAAA0JgAAhSYAAJkmAAC1JgAA5yYAAPomAAD7JgAAKCcAACsnAAAsJwAAWScAAFwnAABdJwAA ZScAAGYnAACZJwAAnCcAAJ0nAACnJwAAuycAALwnAADaJwAA2ycAAO4nAADxJwAA8icAAPwnAAD/ JwAAACgAAC4oAABrKAAAbygAAHUoAACcKAAAnygAAKAoAAANKQAAHykAACApAAAhKQAAgCkAAP39 /f39/f39/f39/f39/f39/f39+vH9/f39/f39/f39/f39/fr6+vrx+v39/f39/f39/f39+v39+vr9 /f39/f396f39/f36/f39/f39/f39/f39/f39/f368fr9AAAOdQFEBAAAAABQEgBdAgAAEHUBRAQA AAAAUBIAVYFdAgAABVWBXQIAA10CAABcgCkAAIYpAADHKQAA3ykAAOgpAAD+KQAAICoAAEwqAABN KgAAZSoAAHAqAABzKgAAdCoAAKMqAADPKgAA1yoAAP0rAAAMLAAAHywAACIsAAArLAAAMCwAADIs AABiLAAA0SwAAFYtAABXLQAAWC0AAGstAABvLQAAcC0AAL0tAADHLQAA3S0AAAwuAAAPLgAAEC4A AF4uAABhLgAAYi4AALkuAAC8LgAAvS4AAA8vAAASLwAAEy8AACkvAAAKMAAAFDAAABUwAAAkMAAA MTAAADwwAAA/MAAAQDAAAKIwAADQMAAA0TAAANMwAADuMAAA7zAAAPkwAADoMQAAKDIAALMyAAC6 MgAAzzIAABUzAAAWMwAAFzMAABgzAAAZMwAAGjMAABszAAAcMwAAHTMAAB4zAAAlMwAAJzMAAD4z AAA/MwAARDMAAEozAABMMwAAaTMAAGozAACMMwAAjzMAAJAzAACgMwAAozMAAKQzAACqMwAAsjMA ALMzAAC0MwAAtTMAAL8zAADDMwAA/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f0AAAAAAAAAAAAA9wAAAAAAAAAA AAD3AAALdQFEBAAAAABQEgADXQIAAGLDMwAAxDMAANwzAADfMwAA4DMAACk0AAAsNAAARzQAAIA0 AACBNAAAgjQAAIQ0AACFNAAAiTQAAOc0AADoNAAA6TQAAG41AABxNQAAcjUAAHY1AACvNQAAsjUA ALM1AAC9NQAAvjUAAL81AADANQAA4TUAAOQ1AADlNQAACTYAAAw2AAANNgAAHTYAAB42AAAfNgAA WzYAAGY2AAB8NgAAgTYAALE2AACyNgAA8DYAAPE2AAAvNwAAAAAAAAAAAAAA+QAAAAAA+QAAAAAA AAAAAAD5AAAAAAAAAAD5AAAAAAAA9wD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAJ1AQALdQFEBAAAAABQEgAALdEdAAASHgAAah4AALceAAC4HgAA4R4AABQfAABEHwAAiR8A ANAfAAAOIAAAUSAAAJogAADeIAAAIiEAAGYhAACbIQAA4iEAADQiAACBIgAAgiIAAJsiAAD1IgAA RiMAAJUjAADkIwAANSQAAI8kAADZJAAANCUAAH8lAADVJQAANCYAAIQmAACFJgAAmSYAAOYmAADn JgAA+yYAADUnAABnJwAApicAAKcnAAC8JwAA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEA AaAy8ADxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QAB oDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGg MvAA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy 5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy8ADxAAGgMuYA8QABoDLm APEAAaAy8ADxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLwAAAAAAAADgAADxcAB/sL EA6bEbATgBYgHPAeAQEBAQAAAAArvCcAAAcoAABhKAAAsigAAAgpAAAJKQAACikAAAspAAAMKQAA DSkAACEpAABnKQAAsSkAAP4pAABFKgAAfCoAANAqAAD6KgAAPCsAAJIrAADfKwAAMiwAAH8sAADR LAAAKC0AAIUtAADeLQAAKy4AAIEuAADRLgAAKS8AAHMvAADHLwAACzAAAFIwAACjMAAA+jAAAEIx AACQMQAA2jEAACQyAAB5MgAA0DIAABYzAADxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QAB oDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMvAA8QABoDLmAPEAAaAy5gDxAAGg MuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy 5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLm APEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYA 8QABoDLmAPEAAaAy5gDxAAGgMuYA8QABoDLmAPEAAaAy5gDxAAGgMuYAAAAAAAAOAAAPFwAH+wsQ DpsRsBOAFiAc8B4BAQEBAAAAACsWMwAAFzMAABozAAAcMwAAHTMAALQzAACBNAAA6DQAAL81AAAe NgAAsjYAAPE2AADxAAGgMuYA8QABoDLmAPEAAaAy5gDvAAAAAAAA7QAAAAAAAO0AAAAAAADtAAAA AAAA7QAAAAAAAO0AAAAAAADtAAAAAAAA7wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEQAAAQAAAA4AAA8XAAf7CxAO mxGwE4AWIBzwHgEBAQEAAAAACxcGAABfBgAAeAgAAOoJAAA/CgAAWwsAANQMAADsDwAAphMAAHIY AAAsGgAAIioAAAEAAgADAAQABQAGAAcACAAJAAoACwAAAAAAYAAAALEAAAAEAQAAYgEAAMABAAAL AgAA2AIAAD8DAAAWBAAAdQQAAAkFAAAMBQAABgAQAf//AQAAAP//AgABAP//AwAAAP//BAAQAP// BQAQAP//BgAAAAAAAAAAAAsCAAA/AwAACQUAAAkFAAAMBQAAAAAAAAAAAQAAAAAAAgDXAAAAAwAA AAAABAAAAAAABQAAAAAAAAAAAPwFAAAiKgAABADxNgAAAwD/////BAAPNwAAAwD/////BgAEIf// AQAAIf//AgAEIP//AwAAIP//BAAEIP//BQACIP//BgAAAAAA/AUAANgLAACoEwAALhoAACskAAAi KgAAAAAAAAAAAQDlAQAAAgCaAQAAAwDdAAAABAABAAAABQAAAAAAAAAAABYAAAAXAAAAnQAAAJ4A AAC+AQAAvwEAACIDAAAjAwAAxgMAAMcDAAAKBQAACwUAAFcFAABYBQAAigUAAIsFAADKBQAAywUA APwFAAALBgAASwYAAKIGAAD0BgAATAcAAKkHAAD3BwAA+AcAAA4IAABaCAAAsQgAAPEIAABBCQAA fgkAAM0JAAAhCgAAcQoAAHIKAACHCgAAxwoAAMgKAADgCgAAMAsAADELAABLCwAAiQsAANYLAADX CwAA2AsAAP4LAABZDAAAugwAALsMAADWDAAAIQ0AAHcNAAC9DQAACQ4AAEQOAACZDgAA3g4AAB8P AAB3DwAAxA8AAMUPAADuDwAAIRAAAFEQAACWEAAA3RAAABsRAABeEQAApxEAAOsRAAAvEgAAcxIA AKgSAADvEgAAQRMAAI4TAACPEwAAqBMAAAIUAABTFAAAohQAAPEUAABCFQAAnBUAAOYVAABBFgAA jBYAAOIWAABBFwAAkRcAAJIXAACmFwAA8xcAAPQXAAAIGAAAQhgAAHQYAACzGAAAtBgAAMkYAAAU GQAAbhkAAL8ZAAAVGgAAFhoAABcaAAAYGgAAGRoAABoaAAAuGgAAdBoAAL4aAAALGwAAUhsAAIkb AADdGwAABxwAAEkcAACfHAAA7BwAAD8dAACMHQAA3h0AADUeAACSHgAA6x4AADgfAACOHwAA3h8A ADYgAACAIAAA1CAAABghAABfIQAAsCEAAAciAABPIgAAnSIAAOciAAAxIwAAhiMAAN0jAAAjJAAA JCQAACckAAApJAAAKyQAACwkAAAtJAAAIioAAAABoDLwAAABoDLwAAABoDLwAAABoDLwAAT/oDLl AQABoDLwAAT/oDLVAgABoDLwAAT/oDLlAQABoDLwAAT/oDLlAQABoDLwAAABoDL1AAABoDLwAAAB oDL1AAABoDLwAAABoDL1AAABoDLwAAABoDLwAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLm AAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAAB oDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLw AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAAAAAAAAAAAAAEAAAA6AAAAOsAAAAAAwAAIxEA AHkcAACAKQAAwzMAAC83AAAJABwAHQAeAB8AAAMAAPQKAABQDwAA0R0AALwnAAAWMwAA8TYAAAoA CwAMACAAIQAiAAAAAABsBgAAbwYAAHYMAAB/DAAAMw0AAEINAAAYDgAAJw4AAGYOAABxDgAA8g4A AP0OAAA+DwAARQ8AAJUPAACcDwAAiBIAAI8SAAAGFgAAExYAAFoWAABpFgAAqxYAALoWAAAAFwAA DxcAAF4XAABtFwAAwhcAANEXAACNGAAAmBgAAKgcAACrHAAACh0AABkdAAAwHQAAMx0AADUdAAA4 HQAAOh0AAD0dAABcHQAAZh0AAKUdAACwHQAAcx4AAHceAAA4HwAAQh8AAMchAADWIQAAIiIAADEi AABrIgAAeiIAALoiAADJIgAADCMAABUjAACfIwAAriMAABkkAAAiJAAALiQAADgpAAAjKgAABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcABAAHAAcABwBKAAtyb2dlciBkZWJyeTtFOlxXSU5OVFxQcm9maWxlc1xBZG1pbmlz dHJhdG9yXFBlcnNvbmFsXElQUCBBdHRyaWJ1dGVzLmRvY/9ATXkgUHJpbnRlcgBMUFQxOgB3aW5z cG9vbABNeSBQcmludGVyAE15IFByaW50ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBA5wAcAAD YwEAAQABAAAAAAAAAAEADwAsAQIAAQAsAQIAAABMZXR0ZXIAAFYARQBSAFMAXABXADMAMgBYADgA NgBcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACAA/////yUDAAAAAAAA//////////8AAAAAAAAHAAEAAwD//wUAAQD//wAAAAAAAP//AAAAAP// //////////////////8AAAIA/////////////wAAAAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAABN eSBQcmludGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAABAA8A LAECAAEALAECAAAATGV0dGVyAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////8lAwAAAAAAAP// ////////AAAAAAAABwABAAMA//8FAAEA//8AAAAAAAD//wAAAAD/////////////////////AAAC AP////////////8AAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAA4ABACIkAAAiJAAABwABAAEA IiQAAAAAAADcIwAAAQIAmQIBAgCZEAENABcJATQXAAAB2hYAmRABNwAXMweaCx4P/BImFjQXCxpw GhkAGQAZABkAGQAZABkAB/QLEA6UEbAT2hYgHPAeAQEBAQAAAJkQAR8AFxsB4D3gPQf7CxAOmxGw E9oWIBzwHgEBAQEAAACZEAEfABcbAeA94D0H+wsQDpsRsBOAFiAc8B4BAQEBAAAAmRABDQAXCQE7 FwAAAYAWAJkQAjQSAAAAAAAA/wEAAAICAACPAgAAoQIAAKMCAACwAgAAtgIAALwCAADFAgAAyAIA AMoCAADQAgAA3AIAAN4CAADkAgAA5QIAAOoCAADzAgAA9AIAAPsCAAD8AgAACgMAAAsDAAAOAwAA GQMAABwDAAAdAwAAIQMAAF4EAABgBAAAYQQAAGIEAABmBAAAbgQAAIsEAACMBAAAjQQAAJUEAACW BAAApQQAAKgEAACpBAAArwQAALEEAAD8BQAACgYAABYGAAAXBgAAGwYAABwGAAAtCAAALggAAM4I AADPCAAA0wgAANQIAAACCQAADwkAAB8JAAAhCQAAXgkAAF8JAABjCQAAZQkAAJ4JAACfCQAAowkA AKQJAAClCQAA9QkAAPcJAABKCgAATAoAAJQKAACVCgAAmAoAAJkKAACgCgAAoQoAAKUKAACnCgAA xgoAAMcKAADgCgAAAACHCgAAxwoAAMgKAADgCgAAMAsAADELAABLCwAAiQsAANYLAADXCwAA2AsA AP4LAABZDAAAugwAALsMAADWDAAAIQ0AAHcNAAC9DQAACQ4AAEQOAACZDgAA3g4AAB8PAAB3DwAA xA8AAMUPAADuDwAAIRAAAFEQAACWEAAA3RAAABsRAABeEQAApxEAAOsRAAAvEgAAcxIAAKgSAADv EgAAQRMAAI4TAACPEwAAqBMAAAIUAABTFAAAohQAAPEUAABCFQAAnBUAAOYVAABBFgAAjBYAAOIW AABBFwAAkRcAAJIXAACmFwAA8xcAAPQXAAAIGAAAQhgAAHQYAACzGAAAtBgAAMkYAAAUGQAAbhkA AL8ZAAAVGgAAFhoAABcaAAAYGgAAGRoAABoaAAAuGgAAdBoAAL4aAAALGwAAUhsAAIkbAADdGwAA BxwAAEkcAACfHAAA7BwAAD8dAACMHQAA3h0AADUeAACSHgAA6x4AADgfAACOHwAA3h8AADYgAACA IAAA1CAAABghAABfIQAAsCEAAAciAABPIgAAnSIAAOciAAAxIwAAhiMAAN0jAAAjJAAAJCQAACck AAApJAAAKyQAACwkAAAtJAAAAysAAAABoDLwAAABoDLwAAABoDLwAAABoDLwAAT/oDLlAQABoDLw AAT/oDLVAgABoDLwAAT/oDLlAQABoDLwAAT/oDLlAQABoDLwAAABoDL1AAABoDLwAAABoDL1AAAB oDLwAAABoDL1AAABoDLwAAABoDLwAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLw AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLwAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLm AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLwAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLm AAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAABoDLmAAAB oDLmAAABoDLmAAABoDLmAAABoDLmAAAAAAAAAAAAAADlAAAAyQEAAMwBAAAAAwAAIxEAAHkcAACA KQAAwzMAAPA2AAAJABwAHQAeAB8AAAMAAPQKAABQDwAA0R0AALwnAAAWMwAAsjYAAAoACwAMACAA IQAiAAAAAABsBgAAbwYAAHYMAAB/DAAAMw0AAEINAAAYDgAAJw4AAGYOAABxDgAA8g4AAP0OAAA+ DwAARQ8AAJUPAACcDwAAiBIAAI8SAAAGFgAAExYAAFoWAABpFgAAqxYAALoWAAAAFwAADxcAAF4X AABtFwAAwhcAANEXAACNGAAAmBgAAKgcAACrHAAACh0AABkdAAAwHQAAMx0AADUdAAA4HQAAOh0A AD0dAABcHQAAZh0AAKUdAACwHQAAcx4AAHceAAA4HwAAQh8AAMchAADWIQAAIiIAADEiAABrIgAA eiIAALoiAADJIgAADCMAABUjAACfIwAAriMAABkkAAAiJAAALiQAADgpAAAEKwAABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcABAAHAAcABwBKAAtyb2dlciBkZWJyeTtFOlxXSU5OVFxQcm9maWxlc1xBZG1pbmlzdHJhdG9y XFBlcnNvbmFsXElQUCBBdHRyaWJ1dGVzLmRvY/9ATXkgUHJpbnRlcgBMUFQxOgB3aW5zcG9vbABN eSBQcmludGVyAE15IFByaW50ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBA5wAcAADYwEAAQAB AAAAAAAAAAEADwAsAQIAAQAsAQIAAABMZXR0ZXIAAFYARQBSAFMAXABXADMAMgBYADgANgBcAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA//// /yUDAAAAAAAA//////////8AAAAAAAAHAAEAAwD//wUAAQD//wAAAAAAAP//AAAAAP////////// //////////8AAAIA/////////////wAAAAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAABNeSBQcmlu dGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAABAA8ALAECAAEA LAECAAAATGV0dGVyAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////8lAwAAAAAAAP////////// AAAAAAAABwABAAMA//8FAAEA//8AAAAAAAD//wAAAAD/////////////////////AAACAP////// //////8AAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAA4ABACIkAAAiJAAABwABAAEAIiQAAAAA AADcIwAAAQIAmQIBAgCZEAENABcJATQXAAAB2hYAmRABNwAXMweaCx4P/BImFjQXCxpwGhkAGQAZ ABkAGQAZABkAB/QLEA6UEbAT2hYgHPAeAQEBAQAAAJkQAR8AFxsB4D3gPQf7CxAOmxGwE9oWIBzw HgEBAQEAAACZEAEfABcbAeA94D0H+wsQDpsRsBOAFiAc8B4BAQEBAAAAmRABDQAXCQE7FwAAAYAW AJkQAjQSAAAAAAAA/wEAAAICAACPAgAAoQIAAKMCAACwAgAAtgIAALwCAADFAgAAyAIAAMoCAADQ AgAA3AIAAN4CAADkAgAA5QIAAOoCAADzAgAA9AIAAPsCAAD8AgAACgMAAAsDAAAOAwAAGQMAABwD AAAdAwAAIQMAAF4EAABgBAAAYQQAAGIEAABmBAAAbgQAAIsEAACMBAAAjQQAAJUEAACWBAAApQQA AKgEAACpBAAArwQAALEEAAD8BQAACgYAABYGAAAXBgAAGwYAABwGAAAtCAAALggAAM4IAADPCAAA 0wgAANQIAAACCQAADwkAAB8JAAAhCQAAXgkAAF8JAABjCQAAZQkAAJ4JAACfCQAAowkAAKQJAACl CQAA9QkAAPcJAABKCgAATAoAAJQKAACVCgAAmAoAAJkKAACgCgAAoQoAAKUKAACnCgAAxgoAAMcK AADgCgAA9goAAPcKAAD6CgAA+woAAAILAAADCwAABwsAAAkLAAAvCwAAMAsAADELAABaCwAAWwsA AFwLAABnCwAAaAsAAGwLAABuCwAAiAsAAJsLAACcCwAApgsAAKcLAACrCwAArQsAANULAADWCwAA 1wsAANgLAADnCwAA/QsAABMMAAAUDAAAFwwAABgMAAAkDAAALwwAADIMAAAzDAAAXwwAAHAMAABx DAAAdAwAAHUMAACCDAAAnAwAAKEMAACmDAAAuQwAALsMAADUDAAA1QwAANYMAADrDAAAIA0AADYN AAA7DQAAPA0AAEINAABlDQAAhg0AALANAACzDQAAtA0AALwNAAAbDgAAIA4AACoOAABmDgAAiw4A AK4OAAC7DgAAwg4AAMoOAADNDgAA0Q4AAN0OAAAGDwAACw8AAB4PAADFDwAA7A8AAO0PAADuDwAA eBAAAL4QAADjEAAAAxEAALsRAADBEQAA/xEAAAUSAABJEgAA2hIAAOYSAADuEgAAjxMAAJATAACR EwAAkxMAAKYTAACnEwAAqBMAAFQVAACqFQAAehYAAH0WAAB+FgAAkRYAAJIWAACiFgAAoxYAAEEX AADCFwAA9BcAAAcYAAA1GAAAOBgAADkYAABmGAAAaRgAAGoYAABzGAAAphgAAKkYAACqGAAAtBgA AMgYAADJGAAA5xgAAOgYAAD7GAAA/hgAAP8YAAAJGQAADBkAAA0ZAAA7GQAAeBkAAHwZAACCGQAA qRkAAKwZAACtGQAAGhoAACwaAAAtGgAAjRoAAJMaAADUGgAA7BoAAPUaAAALGwAALRsAAFkbAABa GwAAchsAAH0bAACAGwAAgRsAALAbAADcGwAA5BsAAAodAAAZHQAALB0AAC8dAAA4HQAAPR0AAD8d AABvHQAA3h0AAGMeAABkHgAAZR4AAHgeAAB8HgAAfR4AAMoeAADUHgAA6h4AABkfAAAcHwAAHR8A AGsfAABuHwAAbx8AAMYfAADJHwAAyh8AABwgAAAfIAAAICAAADYgAAAXIQAAISEAACIhAAAxIQAA PiEAAEkhAABMIQAATSEAAK8hAADdIQAA3iEAAOAhAAD7IQAA/CEAAAYiAAD1IgAANSMAAMAjAADH IwAA3CMAACIkAAAjJAAAJCQAACUkAAAmJAAAJyQAACgkAAApJAAAKyQAAC0kAAAuJAAAjCQAAI0k AADeJAAAMSUAADQlAAA7JQAASSUAAEslAAByJQAAiSUAAIolAACPJQAAkiUAAJglAACnJQAAqSUA ANAlAADtJQAA7iUAABEmAAAUJgAAFSYAACUmAAAoJgAAKSYAAC8mAAA3JgAAOCYAADkmAABEJgAA SCYAAEkmAABhJgAAZCYAAGUmAACuJgAAsSYAAMwmAAAFJwAABicAAAknAAAKJwAADicAAGwnAABt JwAA8ycAAPYnAAD3JwAA+ycAADQoAAA3KAAAOCgAAEIoAABDKAAARCgAAGYoAABpKAAAaigAAI4o AACRKAAAkigAAKIoAACjKAAA4CgAAOsoAAABKQAABikAADYpAAA3KQAAOCkAADkpAAAbKgAAHCoA AB0qAAD/KgAAACsAAAErAAACKwAAAysAAEAAAAMAAAEAQQC7EAAAAABBAAMFAAABAEEAvhAAAAAA QQDQEAAAAABBANIQAAAAAEEA3xAAAAAAQQDlEAAAAABBAOsQAAAAAEEA9BAAAAAAQQD3EAAAAABB APkQAAAAAEEA/xAAAAAAQQALEQAAAABBAA0RAAAAAEEAExEAAAAAQQAUEQAAAABBABkRAAAAAEEA IhEAAAAAQQAjEQAAAABBACoRAAAAAEEAKxEAAAAAQQA5EQAAAABBADoRAAAAAEEAPREAAAAAQQBI EQAAAABBAEsRAAAAAEEATBEAAAAAQAC3BQAAAQBBAFARAAAAAEEAUhEAAAAAQQBTEQAAAABBAFQR AAAAAEEAWBEAAAAAQQBgEQAAAABBAH0RAAAAAEEAfhEAAAAAQQB/EQAAAABBAIcRAAAAAEEAiBEA AAAAQQCXEQAAAABBAJoRAAAAAEEAmxEAAAAAQQChEQAAAABAAPQGAAABAEEAPwgAAAMAQABNCAAA BQBBAKMRAAAAAEEAWggAAAUAQQCkEQAAAABAAF8IAAAFAEEApREAAAAAQABxCgAABQBBAKYRAAAA AEEAEgsAAAUAQQCnEQAAAABAABYLAAAFAEEAqBEAAAAAQQBMCwAABQBBALURAAAAAEAAXAsAAAUA QQC3EQAAAABBAJoLAAAFAEEAuBEAAAAAQACeCwAABQBBALoRAAAAAEEA2QsAAAUAQQC7EQAAAABB ALwRAAAAAEAA3QsAAAUAQQC9EQAAAABAAC0MAAAFAEEAvxEAAAAAQACADAAABQBBAMERAAAAAEEA yQwAAAUAQQDCEQAAAABBAM0MAAAFAEEAwxEAAAAAQQDWDAAABQBBAMQRAAAAAEEA2gwAAAUAQAD5 DAAABwBAAPoMAAAFAEEAFA0AAAUAQQDGEQAAAABBACsNAAAFAEEAxxEAAAAAQQAvDQAABQBBAMgR AAAAAEEAOA0AAAUAQQDJEQAAAABBADwNAAAFAEAAyxEAAAAAQABiDQAABwBAAGMNAAAFAEEAzBEA AAAAQQDNEQAAAABBAI0NAAAFAEEAzhEAAAAAQQCaDQAABQBBAM8RAAAAAEEAng0AAAUAQAC4DQAA CQBBANERAAAAAEEAzA0AAAkAQQDSEQAAAABBANcNAAAJAEEA0xEAAAAAQQDbDQAACQBAANURAAAA AEAA1hEAAAAAQADXEQAAAABBANgRAAAAAEEA5xEAAAAAQADwGgAAAABBAAYbAAAAAEEABxsAAAAA QQAKGwAAAABBAAsbAAAAAEEAFxsAAAAAQQAiGwAAAABBACUbAAAAAEAAJhsAAAAAQQBSGwAAAABB AGMbAAAAAEEAZBsAAAAAQQBnGwAAAABBAGgbAAAAAEEAdRsAAAAAQQCPGwAAAABBAJQbAAAAAEEA mRsAAAAAQACsGwAAAABBAK4bAAAAAEEAxxsAAAAAQADIGwAAAABBAMkbAAAAAEEA3hsAAAAAQAAT HAAAAABBACkcAAAAAEEALhwAAAAAQQAvHAAAAABBADUcAAAAAEAAWBwAAAAAQQB5HAAAAABBAKMc AAAAAEEAphwAAAAAQQCnHAAAAABAAK8cAAAAAEEADh0AAAAAQQATHQAAAABAAB0dAAAAAEEAWR0A AAAAQAB+HQAAAABBAKEdAAAAAEEArh0AAAAAQQC1HQAAAABBAL0dAAAAAEEAwB0AAAAAQQDEHQAA AABAANAdAAAAAEEA+R0AAAAAQQD+HQAAAABAABEeAAAAAEEAuB4AAAAAQQDfHgAAAABAAOAeAAAA AEAA4R4AAAAAQABrHwAAAABAALEfAAAAAEEA1h8AAAAAQAD2HwAAAABBAK4gAAAAAEAAtCAAAAAA QQDyIAAAAABAAPggAAAAAEAAPCEAAAAAQQDNIQAAAABBANkhAAAAAEAA4SEAAAAAQQCCIgAAAABB AIMiAAAAAEEAhCIAAAAAQQCGIgAAAABBAJkiAAAAAEAAmiIAAAAAQACbIgAAAABAAEckAAAAAEAA nSQAAAAAQQBtJQAAAABBAHAlAAAAAEAAcSUAAAAAQQCEJQAAAABBAIUlAAAAAEEAlSUAAAAAQACW JQAAAABAADQmAAAAAEAAtSYAAAAAQQDnJgAAAABAAPomAAAAAEEAKCcAAAAAQQArJwAAAABAACwn AAAAAEEAWScAAAAAQQBcJwAAAABBAF0nAAAAAEAAZicAAAAAQQCZJwAAAABBAJwnAAAAAEAAnScA AAAAQQCnJwAAAABAALsnAAAAAEEAvCcAAAAAQQDaJwAAAABBANsnAAAAAEEA7icAAAAAQQDxJwAA AABBAPInAAAAAEEA/CcAAAAAQQD/JwAAAABAAAAoAAAAAEAALigAAAAAQQBrKAAAAABBAG8oAAAA AEEAdSgAAAAAQQCcKAAAAABBAJ8oAAAAAEAAoCgAAAAAQQANKQAAAABBAB8pAAAAAEAAICkAAAAA QQCAKQAAAABAAIYpAAAAAEEAxykAAAAAQQDfKQAAAABAAOgpAAAAAEEA/ikAAAAAQAAgKgAAAABB AEwqAAAAAEEATSoAAAAAQQBlKgAAAABBAHAqAAAAAEEAcyoAAAAAQAB0KgAAAABBAKMqAAAAAEAA zyoAAAAAQADXKgAAAABBAP0rAAAAAEEADCwAAAAAQQAfLAAAAABBACIsAAAAAEEAKywAAAAAQAAw LAAAAABBADIsAAAAAEAAYiwAAAAAQADRLAAAAABBAFYtAAAAAEEAVy0AAAAAQQBYLQAAAABBAGst AAAAAEEAby0AAAAAQABwLQAAAABBAL0tAAAAAEEAxy0AAAAAQADdLQAAAABBAAwuAAAAAEEADy4A AAAAQAAQLgAAAABBAF4uAAAAAEEAYS4AAAAAQABiLgAAAABBALkuAAAAAEEAvC4AAAAAQAC9LgAA AABBAA8vAAAAAEEAEi8AAAAAQAATLwAAAABAACkvAAAAAEAACjAAAAAAQQAUMAAAAABBABUwAAAA AEEAJDAAAAAAQQAxMAAAAABBADwwAAAAAEEAPzAAAAAAQABAMAAAAABAAKIwAAAAAEEA0DAAAAAA QQDRMAAAAABBANMwAAAAAEEA7jAAAAAAQQDvMAAAAABAAPkwAAAAAEAA6DEAAAAAQAAoMgAAAABB ALMyAAAAAEEAujIAAAAAQADPMgAAAABAABUzAAAAAEAAFjMAAAAAQQAXMwAAAABBABgzAAAAAEAA GTMAAAAAQQAaMwAAAABAABszAAAAAEAABA4AAAsAQAAGDgAADQBAABwzAAAAAEEACQ4AAAAAQQAd MwAAAABAAGgOAAAAAEAAug4AAAAAQAAODwAAAABBAB4zAAAAAEEAFw8AAAAAQQAlMwAAAABBACgP AAAAAEEAJzMAAAAAQQA+MwAAAABBAD8zAAAAAEAAUA8AAAAAQQBEMwAAAABBAFgPAAAAAEEASjMA AAAAQQBqDwAAAABBAEwzAAAAAEAAkg8AAAAAQQBpMwAAAABBAIwzAAAAAEEAjzMAAAAAQQCQMwAA AABBAKAzAAAAAEEAozMAAAAAQQCkMwAAAABBAKozAAAAAEEAsjMAAAAAQACzMwAAAABBALQzAAAA AEEAvzMAAAAAQQDDMwAAAABBAMQzAAAAAEEA3DMAAAAAQQDfMwAAAABBAOAzAAAAAEEAKTQAAAAA QQAsNAAAAABBAEc0AAAAAEAAgDQAAAAAQQCBNAAAAABBAIQ0AAAAAEEAhTQAAAAAQQCJNAAAAABA AOc0AAAAAEEA6DQAAAAAQQBuNQAAAABBAHE1AAAAAEEAcjUAAAAAQQB2NQAAAABBAK81AAAAAEEA sjUAAAAAQQCzNQAAAABBAL01AAAAAEAAvjUAAAAAQQC/NQAAAABBAOE1AAAAAEEA5DUAAAAAQQDl NQAAAABBAAk2AAAAAEEADDYAAAAAQQANNgAAAABAAB02AAAAAEEAHjYAAAAAQQBbNgAAAABBAGY2 AAAAAEEAfDYAAAAAQQCBNgAAAABAALE2AAAAAEAAkw8AAAAAQQCUDwAAAABAAJcPAAAAAEAAlQ8A AAAAQACWDwAAAABAAJcPAAAAAEAAeRAAAAAAQAB6EAAAAABAAHsQAAAAAEAAfBAAAA0AMQAVFpAB AABUaW1lcyBOZXcgUm9tYW4ADBaQAQIAU3ltYm9sAAsmkAEAAEFyaWFsACIABAAxCIgYAADQAgAA aAEAAAAAJLMLpuPKCyYAAAAABQATAQAAOwUAANUdAAAGAA8AAAAEAIMQPwAAAAAAAAAAAAAABgAB AAAAAQAAAAAAAAAhAwAAAAA4AAAADkpvYiBBdHRyaWJ1dGVzAAAAC3JvZ2VyIGRlYnJ5C3JvZ2Vy IGRlYnJ5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3KVo AGPgCQQAABQAZQAAAAAAAAAAAAAAAAMAAH0QAAChZQAAAAAAAAAAAAAAAAAAAAAAAC4kAAAKBQAA ygEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAADwAAAAABoAAPAAAAAARgAARgAAAEZGAAA0 AAAA4EYAAAAAAADgRgAAAAAAAOBGAAAkAAAAaE0AAAAAAABqRwAA/gUAAGhNAAAAAAAAaE0AAAAA AABoTQAAEAAAAHhNAAAiAAAAmk0AACgAAABoTQAAAAAAAOBkAAAxAAAAwk0AAAAAAADCTQAAAAAA AMJNAAAAAAAAwk0AAAAAAADCTQAAAAAAAMJNAAAAAAAAwk0AAAAAAADCTQAAAAAAAKJPAAACAAAA pE8AAAAAAACkTwAAAAAAAKRPAAAlAAAAyU8AAAwBAADVUAAADAEAAOFRAAAeAAAAEWUAAFgAAABp ZQAAOAAAAP9RAADhEgAAAAAAAAAAAAAAAAAAAAAAAOBGAAAAAAAAwk0AAAAAAAAAAAkACgAFAAYA wk0AAAAAAADCTQAAAAAAAAAAAAAAAAAAAAAAAAAAAADCTQAAAAAAAMJNAAAAAAAA/1EAAAAAAABY TwAAAAAAAOBGAAAAAAAA4EYAAAAAAADCTQAAAAAAAAAAAAAAAAAAAAAAAAAAAADCTQAAAAAAAFhP AAAAAAAAWE8AAAAAAABYTwAAAAAAAMJNAACWAQAA4EYAAAAAAADCTQAAAAAAAOBGAAAAAAAAwk0A AAAAAACiTwAAAAAAAAAAAAAAAAAAECzuav/auwEERwAAJgAAACpHAABAAAAAekYAACYAAACgRgAA QAAAAOBGAAAAAAAA4EYAAAAAAADCTQAAAAAAAKJPAAAAAAAAWE8AAEoAAABYTwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASVBQIEF0dHJpYnV0ZSBTdW1tYXJ5DQ1UaGUgZm9sbG93 aW5nIHRhYmxlIHN1bW1hcml6ZXMgdGhlIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgSVBQIHNw ZWNpZmljYXRpb24uICBUaGUgY29sdW1ucyBpbiB0aGUgdGFibGUgaGF2ZSB0aGUgZm9sbG93aW5n IG1lYW5pbmc6DQ1DbGllbnQgdmlldzogVGhlIGNsaWVudCBtYXkgZ2VuZXJhdGUgYSByZXF1ZXN0 IHRvIGdldCB0aGUgdmFsdWUgb2YgdGhpcyBhdHRyaWJ1dGUuICBBIJN5lCBpbiB0aGlzIGNvbHVt biBpbmRpY2F0ZXMgdGhhdCB0aGUgY2xpZW50IG11c3QgYWNjZXB0IHRoZSBhdHRyaWJ1dGUgYW5k IGl0cyBjb3JyZXNwb25kaW5nIHZhbHVlIGluIGEgcmVzcG9uc2UuICBJZiBvciBob3cgYSBjbGll bnQgcHJlc2VudHMgdGhpcyBpbmZvcm1hdGlvbiB0byBhbiBlbmQtdXNlciBpcyBpbXBsZW1lbnRh dGlvbiBkZWZpbmVkLg0NQ2xpZW50IGdlbmVyYXRlOiBBIJN5lCBpbiB0aGlzIGNvbHVtbiBpbmRp Y2F0ZXMgdGhhdCB0aGUgY2xpZW50IG11c3QgZ2VuZXJhdGUgYSB2YWxpZCB2YWx1ZSBmb3IgdGhp cyBhdHRyaWJ1dGUgd2hlbiBzdWJtaXR0aW5nIGEgUHJpbnQgT3BlcmF0aW9uLiBBbiCTbpQgaW5k aWNhdGVzIHRoYXQgYSBjbGllbnQgbXVzdCBub3QgZ2VuZXJhdGUgdGhpcyBhdHRyaWJ1dGUsIGFu IJNvlCBpbmRpY2F0ZXMgdGhhdCBpdCBpcyBvcHRpb25hbC4NDVByaW50ZXIgYWNjZXB0OiBUaGUg UHJpbnRlciBvYmplY3QgbXVzdCBhY2NlcHQgdGhpcyBhdHRyaWJ1dGUgYW5kIHVzZSB0aGUgY29y cmVzcG9uZGluZyBhdHRyaWJ1dGUgdmFsdWUgaW4gdGhlIElQUCBvcGVyYXRpb24gc3BlY2lmaWVk LCBhcyBkZWZpbmVkIGluIHRoZSBJUFAgUkZDLg0NUHJpbnRlciBnZW5lcmF0ZTogQSCTWZQgaW4g dGhpcyBjb2x1bW4gaW5kaWNhdGVzIHRoYXQgdGhlIFByaW50ZXIgb2JqZWN0IG11c3QgZ2VuZXJh dGUgdmFsaWQgdmFsdWVzIGZvciB0aGlzIGF0dHJpYnV0ZSB3aGVuIHJlcXVlc3RlZCBmcm9tIHRo ZSBjbGllbnQuIJNOb25llCBpcyBhbiBhY2NlcHRhYmxlIHZhbHVlIHdoZW4gYW4gYXR0cmlidXRl IGlzIG5vdCBzdXBwb3J0ZWQgYnkgYSBwYXJ0aWN1bGFyIGRldmljZS4NDVN5bnRheDogVGhlIHN5 bnRheCBvZiB0aGUgYXR0cmlidXRlIGFzIHNwZWNpZmllZCBpbiBzZWN0aW9uIDYuMSBvZiB0aGUg UkZDLg0NUy9NOiAgVGhlIGF0dHJpYnV0ZSBpcyBzaW5nbGUgb3IgbXVsdGlwbGUgdmFsdWVkLg0N Q29tbWVudDogIFNob3J0IGRlc2NyaXB0aW9uIG9mIHRoZSBzZW1hbnRpYyBvZiB0aGlzIGF0dHJp YnV0ZS4NDUZvb3Rub3RlcyBkZXNjcmliZSBhbm9tYWxpZXMgb3Igc3BlY2lhbCBjYXNlcy4NDQxK b2IgQXR0cmlidXRlcw1qb2ItbmFtZQl5CW8CCXkJbglzdHJpbmcJcwlodW1hbiByZWFkYWJsZSBz dHJpbmcgbmFtaW5nIHRoZSBqb2INam9iLWlkZW50aWZpZXIJeQluCW4CCXkJc3RyaW5nCXMJdXJs IG9mIHRoaXMgam9iLCB0byBiZSB1c2VkIGZvciBzdWJzZXF1ZW50IG9wZXJhdGlvbnMNam9iLW9y aWdpbmF0b3IJeQluCW4JeQlzdHJpbmcJcwltb3N0IGF1dGhlbnRpY2F0ZWQgdXNlciBuYW1lIG9i dGFpbmVkIGZyb20gY2xpZW50DWpvYi1vcmlnaW5hdGluZy1ob3N0CXkJbgluCXkJc3RyaW5nCXMJ bW9zdCBhdXRoZW50aWNhdGVkIGhvc3QgbmFtZSBvYnRhaW5lZCBmcm9tIGNsaWVudA1ub3RpZmlj YXRpb24tYWRkcmVzcwl5CW4Jbgl5CXN0cmluZwlzCWN1cnJlbnRseSB0aGUgZW1haWwgYWRkcmVz cyBmb3Igbm90aWZpY2F0aW9uIG9mIGV2ZW50cw1qb2ItbG9jYWxlCXkJbgluCXkJdHlwZTNMb2Nh bGUJcwlsb2NhbGUgdG8gYmUgdXNlZCBpbiBhbGwgZXZlbnQgbm90aWZpY2F0aW9ucw0NSm9iIFN0 YXR1cyBBdHRyaWJ1dGVzDWN1cnJlbnQtam9iLXN0YXRlCXkJbgluCXkJdHlwZTFlbnVtCXMJc3Rh dGUgb2YgdGhlIHByaW50IGpvYiBpbiB0aGUgUHJpbnRlcg1vdXRwdXQtZGV2aWNlLWFzc2lnbmVk CXkJbgluCW8CCXN0cmluZwlzCW5hbWUgb2Ygb3V0cHV0IGRldmljZSBhc3NpZ25lZCBieSB0aGUg UHJpbnRlcg1zdWJtaXNzaW9uLXRpbWUJeQluCW4JbwlkYXRlL3RpbWUJCXRpbWUgUHJpbnQgam9i IHdhcyBhY2NlcHRlZA1qb2ItbWVzc2FnZS1mcm9tLW9wZXJhdG9yCXkJbgluCXkJc3RyaW5nCW1l c3NhZ2UgZnJvbSBQcmludGVyIJNvcGVyYXRvcpQNY29tcGxldGlvbi10aW1lCXkJbgluCW8JZGF0 ZS90aW1lCXRpbWUgcHJpbnQgam9iIGNvbXBsZXRlZA1qb2Itc3RhdGUtcmVhc29ucwl5CW4Jbgl5 CXR5cGUgMiBlbnVtCXJlYXNvbiBmb3IgY3VycmVudCBqb2Igc3RhdGUgaW4gUHJpbnRlcg1pbXBy ZXNzaW9ucyBjb21wbGV0ZWQJeQluCW4JbwIJY2FyZGluYWwJbnVtYmVyIG9mIGltcHJlc3Npb25z IFByaW50ZXIgaGFzIHByaW50ZWQNbWVkaWEtc2hlZXRzLWNvbXBsZXRlZAl5CW4JbglvAgljYXJk aW5hbAludW1iZXIgb2Ygc2hlZXRzIFByaW50ZXIgaGFzIHByaW50ZWQNDUpvYiBTaGVldCBBdHRy aWJ1dGVzDWpvYi1zaGVldHMJeQl5CXkJbgl0eXBlIDMgZW51bQljb250cm9scyBwcmludGluZyBv ZiBqb2Igc2hlZXRzDQ1Ob3RpZmljYXRpb24gQXR0cmlidXRlcw0Nbm90aWZpY2F0aW9uIGV2ZW50 cwl5CXkJeQluCXR5cGUgMSBlbnVtCWV2ZW50cyBjbGllbnQgd2FudHMgdG8gYmUgbm90aWZpZWQg Zm9yDUpvYiBTY2hlZHVsaW5nIEF0dHJpYnV0ZXMNam9iLXByaW9yaXR5CXkJeQl5CW4JdHlwZSAy IGVudW0JdXNlZCBpbiBzY2hlZHVsaW5nIHRoZSBqb2INam9iLXByaW50LWFmdGVyCXkJeQl5CW4J ZGF0ZS90aW1lCXByaW50IGFmdGVyIHRoZSBzcGVjaWZpZWQgZGF0ZSBhbmQgdGltZQkJCQ0NDQ0C IElmIG5vdCBzcGVjaWZpZWQsIHRoZSBQcmludGVyIHdpbGwgdXNlIHRoZSBmaWxlIG5hbWUgb2Yg dGhlIGZpcnN0IGRvY3VtZW50IGluIHRoZSBQcmludCBqb2IuDQ0CIFByaW50ZXIgb25seSBzZWVz IGpvYi1pZGVudGlmaWVyIGFzIHRoZSB0YXJnZXQgb2YgYSBVUkwsIG5ldmVyIGFzIGFuIGF0dHJp YnV0ZQ0NAiBPbmx5IHJlcXVpcmVkIHdoZW4gbXVsdGlwbGUgb3V0cHV0IGRldmljZXMgb3BlcmF0 ZSB1bmRlciBhIHNpbmdsZSBQcmludGVyIG9iamVjdA0NAiBFdmVyeSBvdXRwdXQgZGV2aWNlIG1h eSBub3QgYmUgY2FwYWJsZSBvZiByZXBvcnRpbmcgdGhpcyB2YWx1ZQ0NAiBFdmVyeSBvdXRwdXQg ZGV2aWNlIG1heSBub3QgYmUgY2FwYWJsZSBvZiByZXBvcnRpbmcgdGhpcyB2YWx1ZQ0NDSANDUlQ UCBBdHRyaWJ1dGUgU3VtbWFyeQ0NQXR0cmlidXRlICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2xpZW50ICAgICAgICAgICAgICAgIFByaW50ZXIgICAgICAgICAgIHN5bnRh eCAgICAgICAgICBzL20gICBDb21tZW50DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHZpZXcgICAgZ2VuZXJhdGUgICBhY2NlcHQgIGdlbmVyYXRlIA0NDQ0N HACZAqICpOA9pdAvpqAFp6AFqAgHqQgHqgAAqwEAHgCPAZkQogKk4D2l0C+moAWnoAWoCAepCAeq AACrAQBtYXkuIFdoZW4gdW5zcGVjaWZpZWQsIGRlZmF1bHRzIGFyZSB0YWtlbiBmaXJzdCBmcm9t IHRoZSBhc3NvY2lhdGVkIGpvYiBUZW1wbGF0ZSwgc2Vjb25kIGZyb20gdGhlIG91dHB1dCBkZXZp Y2WScyBkZWZhdWx0cywgb3IgYXMgZGVmaW5lZCBpbiB0aGUgUkZDLiBJbiBtYW55IGNhc2VzLCAg dGhpcyBzaW1wbHkgbWVhbnMgcmV0dXJuaW5nIGEgdmFsdWUgb3JpZ2luYWxseSBzZXQgYnkgdGhl IGNsaWVudC4geXlFVHNhZG1pbmlzdHJhdG9ycwlUcwlFbQlzCXMJeXlFcwl5eUVtCQ15AkVzCXlU cwkNDQ1Kb2IgU2NoZWR1bGluZyBBdHRyaWJ1dGVzIChjb250aW51ZWQpAAAAAAMAABcDAACeAwAA qQMAALYDAAC5AwAAIQQAACUEAAC/BAAAzwQAAP8EAAADBQAAcAUAAHgFAACuBQAAtwUAALkFAADI BQAA3AUAAOAFAABdBgAAbgYAAKYGAACqBgAATgcAAFUHAACbBwAAnwcAAM4HAADWBwAAPggAAE4I AABaCAAAWwgAAKIIAACjCAAAOwoAAFEKAAC7CgAAvAoAACIMAAAjDAAAdQwAAHYMAACmDAAAuwwA APsMAAAUDQAAYw0AAH0NAAAIDgAACQ4AAAoOAABpDgAAag4AALsOAAC8DgAADw8AABAPAABRDwAA Ug8AAJQPAACXDwAArQ8AAFQQAAB4EAAAeRAAAHwQAAB9EAAAuxAAAL4QAADQEAAA0hAAAN8QAADl EAAA6xAAAPQQAAD3EAAA+RAAAP8QAAALEQAADREAABMRAAAUEQAAGREAACIRAAAjEQAA/AD6APcA 9wD6APcA9wD3APoA9wD6APcA+gD6APoA/PXt9e31/PXt9e317fX89fz1/PUA5wDnAOcA5wDnAADi /N3bAADZ9wAAAAAAAAAAAAAAAAAAAAACdQEAA2MSAAhVgV0CAGMSAAAIVYFdAgBjGAAAC3UBRAQA AAAAUBIADnUBRAQAAAAAUBIAXQIAAANdAgAEVYFWgQACVYEABVWBXQIAAFYAAwAAFgMAABcDAACd AwAAngMAAL4EAAC/BAAAuAUAALkFAABcBgAAXQYAAE0HAABOBwAAmgcAAJsHAADNBwAAzgcAAA0I AAAOCAAAPQgAAD4IAAA/CAAATggAAI4IAADlCAAANwkAAI8JAADsCQAAOgoAADsKAABRCgAAnQoA APQKAAD0AAAAAAAA9AAAAAAAAPQAAAAAAAD0AAAAAAAA9AAAAAAAAPQAAAAAAAD0AAAAAAAA9AAA AAAAAPQAAAAAAAD0AAAAAAAA9AAAAAAAAPQAAAAAAAD0AAAAAAAA9AAAAAAAAPQAAAAAAAD0AAAA AAAA9AAAAAAAAPQAAAAAAAD0AAAAAAAA9AAAAAAAAPQAAAAAAADhAAAAAAAA0gAAAAAAANIAAAAA AADSAAAAAAAA0gAAAAAAANIAAAAAAADSAAAAAAAAwgAAAAAAALMAAAAAAACzAAAAAAAAswAAAAAA AAAADgAADxcAB/QLEA6UEbATNBcgHPAeAQEBAQAAAAAADwAADxoACPQLEA6UEfwSsBM0FwsaIBwB AQEBAQAAAAAOAAAPFwAH9AsQDpQRsBM0FyAc4h0BAQEBAAAAAAASAAAPIAAK9AsQDpQRsBMYFTQX CxpwGiAc8B4BAQEBAQAAAAAAAAsAAA8RAAX0C8sOGBULGvAeAQEBAAAAIPQKAAAzCwAAfAsAALcL AAAFDAAAVwwAAKUMAACmDAAAuwwAAPoMAAD7DAAAEw0AABQNAABjDQAAfQ0AALkNAAAGDgAABw4A AAgOAAAJDgAAaA4AAGkOAAC6DgAAuw4AAA4PAAAPDwAAUA8AAPEAAAAAAADxAAAAAAAA8QAAAAAA APEAAAAAAADxAAAAAAAA8QAAAAAAANkAAAAAAADZAAAAAAAA2QAAAAAAANkAAAAAAADZAAAAAAAA vgAAAAAAANkAAAAAAACxAAAAAAAAsQABoDLmALEAAaAy5gClAAGgMuYApQABoDLmAJMAAaAy8ACR AAAAAAAAkQAAAAAAAJEAAAAAAACRAAAAAAAAkQAAAAAAAJEAAAAAAACRAAAAAAAAAREAABEAAA8d AAl+CZoL9AsQDssO0g9IEhgVUBkBAQEBAQEAAQAAAAsAAA8RAAV+CZoLEA7SD0gSAQEBAQAAAAwA AA8UAAaaCx4P/BImFgsa8B4BAQEBAAAAGgAADy8AD34Jmgv0CxAOHg/SD5QR/BKwEyYWNBcLGnAa IBzwHgEBAQEBAQEBAQEAAAAAAAAAFwAADykADZoL9AsQDh4PlBH8ErATJhY0FwsacBogHPAeAQEB AQEBAQEAAAAAAAAADgAADxcAB/QLEA6UEbATNBcgHPAeAQEBAQAAAAAaUA8AAFEPAACSDwAAkw8A AJQPAACWDwAAlw8AAK0PAACuDwAAJBAAAHkQAAB6EAAAexAAAHwQAAB9EAAAzBEAANYRAADXEQAA 2BEAAPEaAABMGwAArRsAAK4bAADJGwAAFBwAAGocAACwHAAA/BwAADcdAACMHQAA0R0AAP4AAAAA AAD+AAAAAAAA/gAAAAAAAPwAAAAAAAD6AAAAAAAA/AAAAAAAAPoAAAAAAAD6AAAAAAAA+gAAAAAA APoAAAAAAAD6AAAAAAAA/AAAAAAAAPwAAAAAAADoAAGgMvAA2QABoDLmAMoAAaAy5gC7AAGgMuYA uwABoDLmAKwAAaAy8ACsAAGgMuYArAABoDLmAKwAAaAy5gCsAAGgMvAArAABoDLmAKwAAaAy5gCs AAGgMuYArAABoDLmAKwAAaAy5gCsAAGgMuYArAABoDLmAAAAAAAAAAAAAAAOAAAPFwAH+wsQDpsR sBOAFiAc8B4BAQEBAAAAAAAOAAAPFwAH+wsQDpsRsBM7FyAc8B4BAQEBAAAAAAAOAAAPFwAH+wsQ DpsRsBPaFiAc8B4BAQEBAAAAAAAOAAAPFwAH9AsQDpQRsBPaFiAc8B4BAQEBAAAAAAARAAAPHQAJ fgmaC/QLEA7LDtIPSBIYFVAZAQEBAQEBAAEAAAABDwAAAQAAAAERAB4OABMACAABAEsADwAAAAAA GgAAQPH/AgAaAAZOb3JtYWwAAgAAAAMAYQkEAAAAAAAAAAAAAAAAAAAAAAAAACIAQUDy/6EAIgAW RGVmYXVsdCBQYXJhZ3JhcGggRm9udAAAAAAAAAAAAAAAIAAfQAEA8gAgAAZIZWFkZXIADAAPAA8I AALgEMAhAQIAACAAIEABAAIBIAAGRm9vdGVyAAwAEAAPCAAC4BDAIQECAAAeAB1AAQASAR4ADUZv b3Rub3RlIFRleHQAAAIAEQAAACAAJkCiACEBIAASRm9vdG5vdGUgUmVmZXJlbmNlAAIAaAENam9i LXByaW50LW9mZi1wZWFrCXkJeQl5CXkJdHlwZTNFbnVtCXMJc3BlY2lmaWVzIHRoZSBvZmYgcGVh ayBwZXJpb2QgZm9yIHByaW50aW5nIHRoaXMgam9iDWpvYi1yZXRlbnRpb24tcGVyaW9kCXkJeQl5 CXkJZGVsdGFUaW1lCXMJc2VydmVyIHNoYWxsIGtlZXAgdGhlIGpvYiB0aGlzIG11Y2ggdGltZSBh ZnRlciBwcmludGluZw0NSm9iIFByb2R1Y3Rpb24gQXR0cmlidXRlcwINbWVkaXVtLXNlbGVjdAl5 CXkJeQl5CXR5cGUyRW51bQlzCW1lZGl1bSB0byBiZSB1c2VkIGZvciBwcmludGluZyBhbGwgcGFn ZXMNbnVtYmVyLXVwCXkJeQl5CXkJcG9zaXRpdmVpbnRlZ2VyCXMJbnVtYmVyIG9mIHNvdXJjZSBw YWdlcyB0byBpbXBvc2Ugb24gYSBzaW5nbGUgc2lkZQ1maW5pc2hpbmcJeQl5CXkJeQl0eXBlMkVu dW0JbQlmaW5pc2hpbmcgdG8gYmUgYXBwbGllZCB0byB0aGUgZG9jdW1lbnQNc2lkZXMJeQl5CXkJ eQl0eXBlMkVudW0JcwludW1iZXIgb2Ygc2lkZXMgdG8gcHJpbnQsIGluY2x1ZGluZyB0dW1ibGUt ZHVwbGV4DWNvcGllcwl5CXkJeQl5CXBvc2l0aXZlSW50ZWdlcglzCW51bWJlciBvZiBjb3BpZXMg dG8gcHJpbnQNcHJpbnRlci1yZXNvbHV0aW9uLXNlbGVjdAl5CXkJeQl5CXBvc0ludENyb3NzCXMJ cHJpbnQgcmVzb2x1dGlvbiB0byB1c2UgZm9yIHRoaXMgam9iDXByaW50LXF1YWxpdHkJeQl5CXkJ eQl0eXBlMkVudW0JcwlvdXRwdXQgcXVhbGl0eSB0byB1c2UgZm9yIHRoaXMgam9iDXBhZ2Utc2Vs ZWN0CXkJeQl5CXkJcG9zSW50UmFuZ2UJbQlwcmludCBvbmx5IHRoaXMgcmFuZ2Ugb2YgcGFnZXMN ZmlsZXMtYXJlLW9uZS1kb2N1bWVudAl5CXkJeQl5CWJvb2xlYW4Jcwlmb3IgZmluaXNoaW5nLCB0 cmVhdCBhbGwgZmlsZXMgYXMgb25lIGRvY3VtZW50DWZpbGVzLWFyZSBpbnRlcmxlYXZlZAl5CXkJ eQl5CWJvb2xlYW4Jcwlmb3IgZmluaXNoaW5nLCBmaWxlcyBhcmUgaW50ZXJsZWF2ZWQNDUF0dHJp YnV0ZXMgZm9yIENvbnZlcnNpb24gb2YgVGV4dCBGaWxlcwINd2lkdGgJeQl5CXkJeQljYXJkaW5h bAlzCW1lZGlhIHdpZHRoIGluIGNoYXJhY3RlcnMNbGVuZ3RoCXkJeQl5CXkJY2FyZGluYWwJcwlt ZWRpYSBsZW5ndGggaW4gbGluZXMNbGVmdC1tYXJnaW4JeQl5CXkJeQljYXJkaW5hbAlzCWRvY3Vt ZW50knMgbGVmdCBtYXJnaW4sIGluIGNoYXJhY3RlcnMNcmlnaHQtbWFyZ2luCXkJeQl5CXkJY2Fy ZGluYWwJcwlkb2N1bWVudJJzIHJpZ2h0IG1hcmdpbiwgaW4gY2hhcmFjdGVycw10b3AtbWFyZ2lu CXkJeQl5CXkJY2FyZGluYWwJcwlkb2N1bWVudJJzIHRvcCBtYXJnaW4sIGluIGxpbmVzDWJvdHRv bS1tYXJnaW4JeQl5CXkJeQljYXJkaW5hbAlzCWRvY3VtZW50cyBib3R0b20gbWFyZ2luLCBpbiBs aW5lcw1yZXBlYXRlZC10YWItc3RvcHMJeQl5CXkJeQljYXJkaW5hbAltCWRvY3VtZW50cyB0YWIg c3RvcHMsIGluIGNoYXJhY3RlcnMNaGVhZGVyLXRleHQJeQl5CXkJeQlzdHJpbmcJcwl0ZXh0IHRv IGFwcGx5IGFzIGEgaGVhZGVyIHRvIGVhY2ggcGFnZQ1mb290ZXItdGV4dAl5CXkJeQl5CXN0cmlu ZwlzCXRleHQgdG8gYXBwbHkgYXMgYSBmb290ZXIgdG8gZWFjaCBwYWdlDWZvbnQtc2l6ZQl5CXkJ eQl5CWNhcmRpbmFsCXMJZm9udCBzaXplIGluIHBvaW50cyBmb3IgdGhlIGVudGlyZSBqb2INbnVt YmVyLXBhZ2VzCXkJeQl5CXkJYm9vbGVhbglzCW51bWJlcnMgcGFnZXMgaWYgdHJ1ZQ1kZWZhdWx0 LWZvbnQJeQl5CXkJeQlzdHJpbmcJcwlmb250IHRvIGJlIHVzZWQgZm9yIGFsbCB0ZXh0IGluIHRo aXMgam9iDWRlZmF1bHQtY29kZS1zZXQJeQl5CXkJeQl0eXBlM0VudW0Jcwljb2RlIHNldCB0byBi ZSB1c2VkIGZvciBhbGwgdGV4dCBpbiB0aGlzIGpvYg1jb250ZW50LW9yaWVudGF0aW9uCXkJeQl5 CXkJdHlwZTJFbnVtCXMJb3JpZW50YXRpb24gb2YgdGhlIHBhZ2VzIGluIHRoaXMgam9iDQ1Kb2Ig UmVzb3VyY2UgQXR0cmlidXRlcwINZG9jdW1lbnQtZm9ybWF0LXVzZWQJeQl5CXkJeQkxI3R5cGUy Rm9ybWF0CW0JaWRlbnRpZmllcyB0aGUgUERMIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGRhdGENZm9u dHMtdXNlZAl5CXkJeQl5CTEjc3RyaW5nCW0JaWRlbnRpZmllcyBmb250IHJlc291cmNlcyBuZWVk ZWQgdG8gcHJpbnQgdGhpcyBqb2INY29kZS1zZXRzLXVzZWQJeQl5CXkJeQkxI3R5cGUzRW51bQlt CWlkZW50aWZpZXMgdGhlIGNvZGUgc2V0cyB1c2VkIGluIHRoaXMgam9iDW1lZGlhLXVzZWQJeQl5 CXkJeQkxI3R5cGUyRW51bQltCWlkZW50aWZpZXMgbWVkaWEgcmVxdWlyZWQgdG8gcHJvZHVjZSB0 aGlzIGpvYg1zaWRlcy11c2VkCXkJeQl5CXkJdHlwZTJlbnVtCXMJc3BlY2lmaWVzIGhvdyBtYW55 IHNpZGVzIGFyZSByZXF1aXJlZCBpbiB0aGlzIGpvYg1wcmludC1xdWFsaXR5LXVzZWQJeQl5CXkJ eQl0eXBlMkVudW0JcwlzcGVjaWZpZXMgdGhlIHF1YWxpdHkgdG8gYmUgdXNlZCB0byBwcmludCB0 aGlzIGpvYg1maW5pc2hpbmcgdXNlZAl5CXkJeQl5CXR5cGUyRW51bQlzCXNwZWNpZmllcyB3aGF0 IGZpbmlzaGluZyB0aGUgam9iIG5lZWRzDXByaW50ZXItcmVzb2x1dGlvbi11c2VkCXkJeQl5CXkJ cG9zaW50Y3Jvc3NzdAltCXNwZWNpZmllcyB3aGF0IHJlc29sdXRpb24ocykgdGhlIGpvYiBuZWVk cw10b3RhbC1qb2Itb2N0ZXRzCXkJeQl5CXkJcG9zaXRpdmVJbnRlZ2VyCXMJdG90YWwgc2l6ZSBv ZiB0aGUgam9iIGluIG9jdGV0cw10b3RhbC1pbXByZXNzaW9uLWNvdW50CXkJeQl5CXkJcG9zaXRp dmVJbnRlZ2VyCXMJdG90YWwgc2l6ZSBvZiB0aGUgam9iIGluIGltcHJlc3Npb25zDWpvYi1tZWRp YS1zaGVldC1jb3VudAl5CXkJeQl5CXBvc2l0aXZlSW50ZWdlcglzCXRvdGFsIHNpemUgb2YgdGhl IGpvYiBpbiBtZWRpYSBzaGVldHMgcmVxdWlyZWQNam9iLWludGVydmVuaW5nLWpvYnMJeQl5CXkJ eQlwb3NpdGl2ZUludGVnZXIJcwludW1iZXIgb2Ygam9icyBhaGVhZCBvZiB0aGlzIG9uZQ0NTnVt YmVyIG9mIERvY3VtZW50cw1udW1iZXItb2YtZG9jdW1lbnRzCXkJeQl5CXkJcG9zaXRpdmVJbnRl Z2VyCXMJbnVtYmVyIG9mIGRvY3VtZW50IGluIHRoaXMgam9iDQ1Eb2N1bWVudCBBdHRyaWJ1dGVz DWRvY3VtZW50LWZvcm1hdAl5CXkJeQl5CXR5cGUyRm9ybWF0CXMJUERMIG9mIHRoZSBkb2N1bWVu dA1kb2N1bWVudC1uYW1lCXkJeQl5CXkJbmFtZQlzCVVSTCBvZiB0aGUgZG9jdW1lbnQCDWRvY3Vt ZW50LWNvbnRlbnQJeQl5CXkJeQlvY3RldHN0cmluZwlzCWNvbnRlbnQgb2YgdGhlIGRvY3VtZW50 DQ1PcGVyYXRpb24gQXR0cmlidXRlcw1vcGVyYXRpb24tbG9jYWxlCXkJeQl5CXkJdHlwZTNMb2Nh bGUJcwlpZGVudGlmaWVzIHRoZSBsb2NhbGUgb2YgdGhlIGNsaWVudA1vcGVyYXRpb24tbm90aWZp Y2F0aW9uLWFkZHJlc3MJeQl5CXkJeQlVUkwJcwlhZGRyZXNzIGFuZCBtZWNoYW5pc20gZm9yIGV2 ZW50IG5vdGlmaWNhdGlvbg1vcGVyYXRpb24tdXNlci1uYW1lCXkJeQl5CXkJbmFtZQlzCW1vc3Qg YXV0aGVudGljYXRlZCBuYW1lIHRoZSBjbGllbnQgY2FuIHN1cHBseQ1vcGVyYXRpb24taG9zdC1u YW1lCXkJeQl5CXkJbmFtZQlzCW1vc3QgYXV0aGVudGljYXRlZCBob3N0IG5hbWUgdGhlIGNsaWVu dCBjYW4gc3VwcGx5DQ0NDQ0NUHJpbnRlciBBdHRyaWJ1dGVzAg1wcmludGVyLW5hbWUJeQluCW4J eQluYW1lCXMJdW5pcXVlbHkgaWRlbnRpZmllcyBhIHByaW50ZXIgb24gaXRzIGhvc3QNcHJpbnRl ci1sb2NhdGlvbgl5CW4Jbgl5CXN0cmluZwlzCWlkZW50aWZpZXMgdGhlIGxvY2F0aW9uIG9mIHRo aXMgcHJpbnRlcg1wcmludGVyLW1vZGVsCXkJbgluCXkJc3RyaW5nCXMJaWRlbnRpZmllcyB0aGUg bWFrZSBhbmQgbW9kZWwgb2YgdGhpcyBwcmludGVyDXByaW50ZXItdHlwZXMJeQluCW4JeQl0eXBl MkVudW0JbQltYXJraW5nIHRlY2hub2xvZ3kgb2YgdGhlIHByaW50ZXIocykNcHJpbnRlci1zdGF0 ZQl5CW4Jbgl5CXR5cGUxRW51bQlzCXN0YXRlIG9mIHRoZSBQcmludGVyDXByaW50ZXItc3RhdGUt bWVzc2FnZQl5CW4Jbgl5CXN0cmluZwlzCWdpdmVzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHN0YXRlDW1lc3NhZ2UJeQluCW4JeQlzdHJpbmcJcwlvcGVyYXRvciBtZXNzYWdlDWxv Y2FsZQl5CW4Jbgl5CXR5cGUzTG9jYWxlCXMJbG9jYWxlIHRoYXQgdGhpcyBQcmludGVyIG9wZXJh dGVzIGluDW5vdGlmaWNhdGlvbi1ldmVudHMJeQluCW4JeQkjdHlwZTJFbnVtCW0JYWRkcmVzcyBQ cmludGVyIHNob3VsZCBzZW5kIG5vdGlmaWNhdGlvbnMgdG8NZW5kLXVzZXItYWNsCXkJbgluCXkJ I25hbWUJbQllbmQgdXNlcnMgd2hvIGFyZSBhYmxlIHRvIHByaW50IG9uIHRoaXMgUHJpbnRlcg1t YXhpbXVtLXByaW50ZXItc3BlZWQJeQluCW4JeQlwb3NpdGl2ZUludGVnZXIJcwl1bml0cyBvZiBz cGVlZCAoaW4gIHBwbSwgbHBtLCBldGMpDWZvbnRzLXN1YnN0aXR1dGlvbnMJeQluCW4JeQkjc3Ry aW5ncGFpcgltCWZvbnRzIHRoYXQgcHJpbnRlciB3aWxsIHN1YnN0aXR1dGUNZm9udHMtc3VwcG9y dGVkCXkJbgluCXkJI3N0cmluZ1N0YXRlCW0JZm9udCByZXNvdXJjZXMgYW5kIHJlYWRpbmVzcyBz dGF0ZSBvZiBlYWNoDW1lZGlhLXN1cHBvcnRlZAl5CW4Jbgl5CTEjbmFtZVN0YXRlCW0JbWVkaWEs IG1lZGlhLXNpemVzLCBpbnB1dCB0cmF5cyBmb3IgdGhpcyBwcmludGVyDWRvY3VtZW50LWZvcm1h dHMtc3VwcG9ydGVkCXkJbgluCXkJMSN0eXBlMkZvcm1TdAltCWFsbCBvZiB0aGUgUERMcyB0aGF0 IHRoaXMgUHJpbnRlciBhY2NlcHRzDW51bWJlcnMtdXAtc3VwcG9ydGVkCXkJbgluCXkJMSNwb3NJ bnRTdGF0ZQltCWFsbCBvZiB0aGUgaW1wb3NpdGlvbiBhdHRyaWJ1dGVzIHN1cHBvcnRlZCANc2lk ZXMtc3VwcG9ydGVkCXkJbgluCXkJMSN0eXBlMkVudW1TCW0JYWxsIG9mIHRoZSBzaWRlcyBhdHRy aWJ1dGVzIHN1cHBvcnRlZA1maW5pc2hpbmdzLXN1cHBvcnRlZAl5CW4Jbgl5CTEjdHlwZTJFbnVt UwltCWFsbCBvZiB0aGUgZmluaXNoaW5nIGF0dHJpYnV0ZXMgc3VwcG9ydGVkDXByaW50LXF1YWxp dGllcy1zdXBwb3J0ZWQJeQluCW4JeQkxI3R5cGUyRW51bVMJbQlhbGwgb2YgdGhlIHF1YWxpdGll cyBzdXBwb3J0ZWQNcHJpbnRlci1yZXNvbHV0aW9ucy1zdXBwb3J0ZWQJeQluCW4JeQkxI3Bvc0lu dENyb3NzUwltCWFsbCBvZiB0aGUgcmVzb2x1dGlvbnMgc3VwcG9ydGVkDWNvZGUtc2V0cy1zdXBw b3J0ZWQJeQluCW4JeQkxI3R5cGUzRW51bVMJbQlhbGwgb2YgdGhlIGNvZGUgc2V0cyBzdXBwb3J0 ZWQNb2ZmLXBlYWstdGltZXMtc3VwcG9ydGVkCXkJbgluCXkJMSN0eXBlM0VudW1TCW0JYWxsIG9m IHRoZSBvZmYtcGVhay10aW1lcyBzdXBwb3J0ZWQNZXZlbnRzLXN1cHBvcnRlZAl5CW4Jbgl5CTEj dHlwZTJFbnVtUwltCWFsbCBvZiB0aGUgZXZlbnRzIHN1cHBvcnRlZA1sb2NhbGVzLXN1cHBvcnRl ZAl5CW4Jbgl5CTEjdHlwZTNMb2NhbFMJbQlhbGwgb2YgdGhlIGxvY2FsZXMgc3VwcG9ydGVkDWpv Yi1zaGVldHMtc3VwcG9ydGVkCXkJbgluCXkJI3R5cGUzRW51bVMJbQlhbGwgb2YgdGhlIGpvYiBz aGVldCB2YWx1ZXMgc3VwcG9ydGVkDW1heGltdW0tY29waWVzCXkJbgluCXkJcG9zaXRpdmVJbnRl Z2VyCXMJbWF4aW11bSBudW1iZXIgb2YgY29waWVzIHdoaWNoIGNhbiBiZSBwcmludGVkDW1heGlt dW0tam9iLW9jdGV0cwl5CW4Jbgl5CXBvc2l0aXZlSW50ZWdlcglzCW1heGltdW0gam9iIHNpemUg aW4gb2N0ZXRzDW1heGltdW0taW1wcmVzc2lvbnMJeQluCW4JeQlwb3NpdGl2ZUludGVnZXIJcwlt YXhpbXVtIGpvYiBzaXplIGluIGltcHJlc3Npb25zDW1heGltdW0tbWVkaWEtc2hlZXRzCXkJbglu CXkJcG9zaXRpdmVJbnRlZ2VyCXMJbWF4aW11bSBqb2Igc2l6ZSBpbiBzaGVldHMNbWF4aW11bS1q b2ItcmV0ZW50aW9uLXBlcmlvZAl5CW4Jbgl5CWRlbHRhVGltZQlzCW1heGltdW0gcmV0ZW50aW9u IHBlcmlvZA1tYXhpbXVtLWVuZC11c2VyLXByaW9yaXR5CXkJbgluCXkJdHlwZTFFbnVtCXMJbWF4 aW11bSBwcmlvcml0eSB0aGF0IGNhbiBiZSBzcGVjaWZpZWQNcXVldWVkLWpvYi1jb3VudAl5CW4J bgl5CXBvc2l0aXZlSW50ZWdlcglzCW51bWJlciBvZiBqb2JzIGVpdGhlciBwZW5kaW5nIG9yIHBy b2Nlc3NpbmcNc2NoZWR1bGluZy1hbGdvcml0aG0JeQluCW4JeQl0eXBlM0VudW0JcwljdXJyZW50 IHNjaGVkdWxpbmcgYWxnb3JpdGhtDQ0JCQ0JDQ0gSWYgdGhlIGlzIGl0IHNob3VsZCByZW1haW4g dW5zcGVjaWZpZWRJZiB0aGVpcyBpdCBzaG91bGQgcmVtYWluIHVuc3BlY2lmaWVkAiBJZiBubyBw cmlvcml0eSBpcyBzcGVjaWZpZWQgdGhlbiB0aGUgUHJpbnRlciBhc3NpZ25zIHRoZSB2YWx1ZSCT ZGVmYXVsdJQNAiBSZXF1ZXN0cyBzb21lIGZlYXR1cmUgbm90IGltYmVkZGVkIGluIHRoZSBQREwg aXRzZWxmLiBUaGUgcHJlY2VkZW5jZSBvZiB0aPYKAAD3CgAA+goAAPsKAAACCwAAAwsAAAcLAAAJ CwAALwsAADALAAAxCwAAWgsAAFsLAABcCwAAZwsAAGgLAABsCwAAbgsAAIgLAACbCwAAnAsAAKYL AACnCwAAqwsAAK0LAADVCwAA1gsAANcLAADYCwAA5wsAAP0LAAATDAAAFAwAABcMAAAYDAAAJAwA AC8MAAAyDAAAMwwAAF8MAABwDAAAcQwAAHQMAAB1DAAAggwAAJwMAAChDAAApgwAALkMAAC7DAAA 1AwAANUMAADWDAAA6wwAACANAAA2DQAAOw0AADwNAABCDQAAZQ0AAIYNAACwDQAAsw0AALQNAAC8 DQAAGw4AACAOAAAqDgAAZg4AAIsOAACuDgAAuw4AAMIOAADKDgAAzQ4AANEOAADdDgAABg8AAAsP AAAeDwAAxQ8AAOwPAADtDwAA7g8AAHgQAAC+EAAA4xAAAAMRAAC7EQAAwREAAP8RAAAFEgAASRIA ANoSAADmEgAA7hIAAI8TAACQEwAAkRMAAJMTAACmEwAApxMAAKgTAABUFQAAqhUAAHoWAAB9FgAA fhYAAJEWAACSFgAAohYAAKMWAABBFwAAwhcAAPQXAAAHGAAANRgAADgYAAA5GAAAZhgAAGkYAABq GAAAcxgAAKYYAACpGAAAqhgAALQYAADIGAAAyRgAAOcYAADoGAAA+xgAAP4YAAD/GAAACRkAAAwZ AAANGQAAOxkAAHgZAAB8GQAAghkAAKkZAACsGQAArRkAABoaAAAsGgAALRoAAI0aAACTGgAA1BoA AOwaAAD1GgAACxsAAC0bAABZGwAAWhsAAHIbAAB9GwAAgBsAAIEbAACwGwAA3BsAAOQbAAAKHQAA GR0AACwdAAAvHQAAOB0AAD0dAAA/HQAAbx0AAN4dAABjHgAAZB4AAGUeAAB4HgAAfB4AAH0eAADK HgAA1B4AAOoeAAAZHwAAHB8AAB0fAABrHwAAbh8AAG8fAADGHwAAyR8AAMofAAAcIAAAHyAAACAg AAA2IAAAFyEAACEhAAAiIQAAMSEAAD4hAABJIQAATCEAAE0hAACvIQAA3SEAAN4hAADgIQAA+yEA APwhAAAGIgAA9SIAADUjAADAIwAAxyMAANwjAAAiJAAAIyQAACQkAAAlJAAAJiQAACckAAAoJAAA KSQAACskAAAtJAAALiQAAIwkAACNJAAA3iQAADElAAA0JQAAOyUAAEklAABLJQAAciUAAIklAACK JQAAjyUAAJIlAACYJQAApyUAAKklAADQJQAA7SUAAO4lAAARJgAAFCYAABUmAAAlJgAAKCYAACkm AAAvJgAANyYAADgmAAA5JgAARCYAAEgmAABJJgAAYSYAAGQmAABlJgAAriYAALEmAADMJgAABScA AAYnAAAJJwAACicAAA4nAABsJwAAbScAAPMnAAD2JwAA9ycAAPsnAAA0KAAANygAADgoAABCKAAA QygAAEQoAABmKAAAaSgAAGooAACOKAAAkSgAAJIoAACiKAAAoygAAOAoAADrKAAAASkAAAYpAAA2 KQAANykAADgpAAA5KQAAOikAADspAAA8KQAAHioAAB8qAAAgKgAAISoAACIqAABAAAADAAABAEEA uxAAAAEAQQADBQAAAQBBAL4QAAABAEEA0BAAAAEAQQDSEAAAAQBBAN8QAAABAEEA5RAAAAEAQQDr EAAAAQBBAPQQAAABAEEA9xAAAAEAQQD5EAAAAQBBAP8QAAABAEEACxEAAAEAQQANEQAAAQBBABMR AAABAEEAFBEAAAEAQQAZEQAAAQBBACIRAAABAEEAIxEAAAEAQQAqEQAAAQBBACsRAAABAEEAOREA AAEAQQA6EQAAAQBBAD0RAAABAEEASBEAAAEAQQBLEQAAAQBBAEwRAAABAEAAtwUAAAEAQQBQEQAA AQBBAFIRAAABAEEAUxEAAAEAQQBUEQAAAQBBAFgRAAABAEEAYBEAAAEAQQB9EQAAAQBBAH4RAAAB AEEAfxEAAAEAQQCHEQAAAQBBAIgRAAABAEEAlxEAAAEAQQCaEQAAAQBBAJsRAAABAEEAoREAAAEA QAD0BgAAAQBBAD8IAAADAEAATQgAAAUAQQCjEQAAAABBAFoIAAAFAEEApBEAAAAAQABfCAAABQBB AKURAAAAAEAAcQoAAAUAQQCmEQAAAABBABILAAAFAEEApxEAAAAAQAAWCwAABQBBAKgRAAAAAEEA TAsAAAUAQQC1EQAAAABAAFwLAAAFAEEAtxEAAAAAQQCaCwAABQBBALgRAAAAAEAAngsAAAUAQQC6 EQAAAABBANkLAAAFAEEAuxEAAAAAQQC8EQAAAABAAN0LAAAFAEEAvREAAAAAQAAtDAAABQBBAL8R AAAAAEAAgAwAAAUAQQDBEQAAAABBAMkMAAAFAEEAwhEAAAAAQQDNDAAABQBBAMMRAAAAAEEA1gwA AAUAQQDEEQAAAABBANoMAAAFAEAA+QwAAAcAQAD6DAAABQBBABQNAAAFAEEAxhEAAAAAQQArDQAA BQBBAMcRAAAAAEEALw0AAAUAQQDIEQAAAABBADgNAAAFAEEAyREAAAAAQQA8DQAABQBAAMsRAAAA AEAAYg0AAAcAQABjDQAABQBBAMwRAAAAAEEAzREAAAAAQQCNDQAABQBBAM4RAAAAAEEAmg0AAAUA QQDPEQAAAABBAJ4NAAAFAEAAuA0AAAkAQQDREQAAAABBAMwNAAAJAEEA0hEAAAAAQQDXDQAACQBB ANMRAAAAAEEA2w0AAAkAQADVEQAAAABAANYRAAAAAEAA1xEAAAAAQQDYEQAAAABBAOcRAAAAAEAA 8BoAAAAAQQAGGwAAAABBAAcbAAAAAEEAChsAAAAAQQALGwAAAABBABcbAAAAAEEAIhsAAAAAQQAl GwAAAABAACYbAAAAAEEAUhsAAAAAQQBjGwAAAABBAGQbAAAAAEEAZxsAAAAAQQBoGwAAAABBAHUb AAAAAEEAjxsAAAAAQQCUGwAAAABBAJkbAAAAAEAArBsAAAAAQQCuGwAAAABBAMcbAAAAAEAAyBsA AAAAQQDJGwAAAABBAN4bAAAAAEAAExwAAAAAQQApHAAAAABBAC4cAAAAAEEALxwAAAAAQQA1HAAA AABAAFgcAAAAAEEAeRwAAAAAQQCjHAAAAABBAKYcAAAAAEEApxwAAAAAQACvHAAAAABBAA4dAAAA AEEAEx0AAAAAQAAdHQAAAABBAFkdAAAAAEAAfh0AAAAAQQChHQAAAABBAK4dAAAAAEEAtR0AAAAA QQC9HQAAAABBAMAdAAAAAEEAxB0AAAAAQADQHQAAAABBAPkdAAAAAEEA/h0AAAAAQAARHgAAAABB ALgeAAAAAEEA3x4AAAAAQADgHgAAAABAAOEeAAAAAEAAax8AAAAAQACxHwAAAABBANYfAAAAAEAA 9h8AAAAAQQCuIAAAAABAALQgAAAAAEEA8iAAAAAAQAD4IAAAAABAADwhAAAAAEEAzSEAAAAAQQDZ IQAAAABAAOEhAAAAAEEAgiIAAAAAQQCDIgAAAABBAIQiAAAAAEEAhiIAAAAAQQCZIgAAAABAAJoi AAAAAEAAmyIAAAAAQABHJAAAAABAAJ0kAAAAAEEAbSUAAAAAQQBwJQAAAABAAHElAAAAAEEAhCUA AAAAQQCFJQAAAABBAJUlAAAAAEAAliUAAAAAQAA0JgAAAABAALUmAAAAAEEA5yYAAAAAQAD6JgAA AABBACgnAAAAAEEAKycAAAAAQAAsJwAAAABBAFknAAAAAEEAXCcAAAAAQQBdJwAAAABAAGYnAAAA AEEAmScAAAAAQQCcJwAAAABAAJ0nAAAAAEEApycAAAAAQAC7JwAAAABBALwnAAAAAEEA2icAAAAA QQDbJwAAAABBAO4nAAAAAEEA8ScAAAAAQQDyJwAAAABBAPwnAAAAAEEA/ycAAAAAQAAAKAAAAABA AC4oAAAAAEEAaygAAAAAQQBvKAAAAABBAHUoAAAAAEEAnCgAAAAAQQCfKAAAAABAAKAoAAAAAEEA DSkAAAAAQQAfKQAAAABAACApAAAAAEEAgCkAAAAAQACGKQAAAABBAMcpAAAAAEEA3ykAAAAAQADo KQAAAABBAP4pAAAAAEAAICoAAAAAQQBMKgAAAABBAE0qAAAAAEEAZSoAAAAAQQBwKgAAAABBAHMq AAAAAEAAdCoAAAAAQQCjKgAAAABAAM8qAAAAAEAA1yoAAAAAQQD9KwAAAABBAAwsAAAAAEEAHywA AAAAQQAiLAAAAABBACssAAAAAEAAMCwAAAAAQQAyLAAAAABAAGIsAAAAAEAA0SwAAAAAQQBWLQAA AABBAFctAAAAAEEAWC0AAAAAQQBrLQAAAABBAG8tAAAAAEAAcC0AAAAAQQC9LQAAAABBAMctAAAA AEAA3S0AAAAAQQAMLgAAAABBAA8uAAAAAEAAEC4AAAAAQQBeLgAAAABBAGEuAAAAAEAAYi4AAAAA QQC5LgAAAABBALwuAAAAAEAAvS4AAAAAQQAPLwAAAABBABIvAAAAAEAAEy8AAAAAQAApLwAAAABA AAowAAAAAEEAFDAAAAAAQQAVMAAAAABBACQwAAAAAEEAMTAAAAAAQQA8MAAAAABBAD8wAAAAAEAA QDAAAAAAQACiMAAAAABBANAwAAAAAEEA0TAAAAAAQQDTMAAAAABBAO4wAAAAAEEA7zAAAAAAQAD5 MAAAAABAAOgxAAAAAEAAKDIAAAAAQQCzMgAAAABBALoyAAAAAEAAzzIAAAAAQAAVMwAAAABAABYz AAAAAEEAFzMAAAAAQQAYMwAAAABAABkzAAAAAEEAGjMAAAAAQAAbMwAAAABAAAQOAAALAEAABg4A AA0AQADwNgAAAABBAAkOAAAAAEEAHTMAAAAAQABoDgAAAABAALoOAAAAAEAADg8AAAAAQQAeMwAA AABBABcPAAAAAEEAJTMAAAAAQQAoDwAAAABBACczAAAAAEEAPjMAAAAAQQA/MwAAAABAAFAPAAAA AEEARDMAAAAAQQBYDwAAAABBAEozAAAAAEEAag8AAAAAQQBMMwAAAABAAJIPAAAAAEEAaTMAAAAA QQCMMwAAAABBAI8zAAAAAEEAkDMAAAAAQQCgMwAAAABBAKMzAAAAAEEApDMAAAAAQQCqMwAAAABB ALIzAAAAAEAAszMAAAAAQQC0MwAAAABBAL8zAAAAAEEAwzMAAAAAQQDEMwAAAABBANwzAAAAAEEA 3zMAAAAAQQDgMwAAAABBACk0AAAAAEEALDQAAAAAQQBHNAAAAABAAIA0AAAAAEEAgTQAAAAAQQCE NAAAAABBAIU0AAAAAEEAiTQAAAAAQADnNAAAAABBAOg0AAAAAEEAbjUAAAAAQQBxNQAAAABBAHI1 AAAAAEEAdjUAAAAAQQCvNQAAAABBALI1AAAAAEEAszUAAAAAQQC9NQAAAABAAL41AAAAAEEAvzUA AAAAQQDhNQAAAABBAOQ1AAAAAEEA5TUAAAAAQQAJNgAAAABBAAw2AAAAAEEADTYAAAAAQAAdNgAA AABBAB42AAAAAEEAWzYAAAAAQQBmNgAAAABBAHw2AAAAAEEAgTYAAAAAQACxNgAAAABAAJMPAAAA AEEAlA8AAAAAQAB4EAAAAABAAJUPAAAAAEAAlg8AAAAAQACXDwAAAABAAHkQAAAAAEAAehAAAAAA QAB7EAAAAABAAHwQAAANADEAFRaQAQAAVGltZXMgTmV3IFJvbWFuAAwWkAECAFN5bWJvbAALJpAB AABBcmlhbAAiAAQAMQiIGAAA0AIAAGgBAAAAACSzC6YTywsm5soLJgYAIAEAADsFAADVHQAABgAP AAAABACDED8AAAAAAAAAAAAAAAYAAQAAAAEAAAAAAAAAIQMAAAAAOAAAAA5Kb2IgQXR0cmlidXRl cwAAAAtyb2dlciBkZWJyeQtyb2dlciBkZWJyeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA== --Boundary=_0.0_=5030100002252180-- From ipp-archive Mon Nov 25 18:48:07 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17181 for ipp-outgoing; Mon, 25 Nov 1996 18:44:51 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 25 Nov 1996 16:44:46 -0700 From: "Scott A. Isaacson" To: ipp@pwg.org Subject: IPP> IPP Internet-Draft Sender: ipp-owner@pwg.org Precedence: first-class Status: RO We now have an Internet Draft for the IPP/1.0 specification!!! Thanks to all who have spent so much time over the last few weeks. The IETF responded with a file name: draft-isaacson-ipp-info-00.txt. Look for it soon on the ietf-announce mailing list. I also put the following files in ftp://ftp.pwg.org/pub/ipp/drafts draft-isaacson-ipp-info-00.txt just now submitted to internet-drafts@ietf.org ipp94.doc same as draft-isaacson-ipp-info-00.txt w/line numbers ipp94.pdf " " PDF file ipp94rev.doc rev marks agains ipp93 ipp94rev.pdf " " PDF file The ipp94 filename suggests version 0.94, but there is no version string in the document any more. It is just draft-isaacson-ipp-info-00.txt. Tom did extensive editing from 0.93, and I have kept most of it. Thank you. However, I removed some of the text he added which raised additional issues about Job Templates. I have preserved these and will be posting them soon so that we can review these suggestions during our next working meetings. Carl-Uno, put this on the agenda. Thanks again. We have much to resolve, but we have already come a long way! Scott ************************************************************ Scott A. Isaacson Print Services Consulting Engineer Novell Inc., 122 E 1700 S, Provo, UT 84606 V: (801) 861-7366, (800) 453-1267 x17366 F: (801) 861-4025, E: scott_isaacson@novell.com W: http://www.novell.com ************************************************************ From ipp-archive Mon Nov 25 18:48:07 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA17130 for ipp-outgoing; Mon, 25 Nov 1996 18:44:20 -0500 (EST) Date: Mon, 25 Nov 1996 15:41:00 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611252341.PAA01101@woden.eng.sun.com> To: robert.herriot@Eng.Sun.COM, rdebry@us1.ibm.com Subject: Re: IPP> job attributes et by Printer Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO My intent is that certain attributes be set by a Printer to the most authentic value that a server can obtain. The operation attributes are a possible source of these values. I would prefer that the information come from something outside of the entity body. If these attributes are settable by a client, then the Printer doesn't know whether a trusted part of the client set them. The operation attributes are useful because a client supplies them for any operation including Print. Only with Print does a Printer possibly copy those values into job attributes. Bob Herriot > From rdebry@us1.ibm.com Mon Nov 25 15:24:03 1996 > From: rdebry@us1.ibm.com > X400-Originator: rdebry@us1.ibm.com > X400-Recipients: non-disclosure:; > X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002247146000002] > X400-Content-Type: P2-1988 (22) > To: > Cc: > Subject: IPP> job attributes et by Printer > Date: Mon, 25 Nov 1996 10:12:48 -0500 > Sender: ipp-owner@pwg.org > Content-Length: 411 > X-Lines: 9 > > Classification: > Prologue: > Epilogue: > > Bob, can you explain the rationale behind setting job information attributes > such as notification address in the Printer, thus requiring a separate set of > operation attributes to be defined to set them? I find this confusing. If the > intent is that the client and not the end-user sets these attributes, can't > this be taken care of in the implementation of the client code? > From ipp-archive Mon Nov 25 19:28:08 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17513 for ipp-outgoing; Mon, 25 Nov 1996 19:23:25 -0500 (EST) Date: Mon, 25 Nov 1996 16:23:31 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611260023.QAA01202@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us1.ibm.com Subject: Re: IPP> job-message-from-administrator attribute (section 6.2.3.4) X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I agree. It is more likely that an operator would create such a message. > From rdebry@us1.ibm.com Mon Nov 25 15:27:50 1996 > From: rdebry@us1.ibm.com > X400-Originator: rdebry@us1.ibm.com > X400-Recipients: ipp@pwg.org > X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002247230000002] > X400-Content-Type: P2-1988 (22) > To: > Subject: IPP> job-message-from-administrator attribute (section 6.2.3.4) > Date: Mon, 25 Nov 1996 10:26:50 -0500 > Sender: ipp-owner@pwg.org > Content-Length: 140 > X-Lines: 6 > > Classification: > Prologue: > Epilogue: > > From the description, it sounds like the name of this attribute should be > "job-message-from-operator". > From ipp-archive Mon Nov 25 19:28:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17686 for ipp-outgoing; Mon, 25 Nov 1996 19:27:03 -0500 (EST) Date: Mon, 25 Nov 1996 16:27:08 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611260027.QAA01211@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us1.ibm.com Subject: Re: IPP> Re: deBry security proposal X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO That was my reading too. But as more applications use HTTP, it will become more important that clients identify themselves in the initial transaction. I am hoping that HTTP applications send along authentication information. But I have a feeling that it is a hope and not current reality. Bob Herriot > From rdebry@us1.ibm.com Mon Nov 25 15:31:33 1996 > From: rdebry@us1.ibm.com > X400-Originator: rdebry@us1.ibm.com > X400-Recipients: ipp@pwg.org > X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245423000002] > X400-Content-Type: P2-1988 (22) > To: > Subject: IPP> Re: deBry security proposal > Date: Mon, 25 Nov 1996 07:44:45 -0500 > Sender: ipp-owner@pwg.org > Content-Length: 1228 > X-Lines: 38 > > Classification: > Prologue: > Epilogue: > > I read 1945 as authorization it NOT typically included, but sent only when > requested by the server. However, I agree that the specification leaves soem > room for interpretation. > > ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 11/25/96 05:32 > AM --------------------------- > > ipp-owner @ pwg.org > 11/23/96 12:31 AM > > > To: ipp @ pwg.org@internet > cc: > Subject: Re: deBry security proposal > > > I would like to know if Authorization is typically included with an HTTP message > or only if a server requests it. RFC 1945 is unclear on this point. > > I ask this because I would like one form of security to be where the client (not > the end-user) automatically sends an attribute at the HTTP level with the user's > name and ideally the domain name as well. > > Such values could implement the attributes operation-user-name and > operation-host-name. This mechanism would allow a lightweight security > mechanism that would work in cooperative environments where people don't want to > deal with passwords but also don't want to cancel other people's jobs > accidentally. > > I think that this is one case that Roger missed in his enumeration of possible > security mechanisms. > > Bob Herriot > > From ipp-archive Mon Nov 25 19:33:06 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17884 for ipp-outgoing; Mon, 25 Nov 1996 19:28:27 -0500 (EST) Message-Id: <2.2.32.19961126002507.009627e0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 1996 16:25:07 PST To: Harald.T.Alvestrand@uninett.no, agenda@ietf.org From: Carl-Uno Manros Subject: IPP> Document IDs for IPP drafts Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Harald & the IETF Agenda Team, in the updated BOF Agenda for IPP (originally called LDPA) on Thursday December 12 (submitted to IETF by Harald), we did not have the actual document titles yet. Below are the two titles now allocated by the IETF: Requirements: draft-wright-ipp-req-00.txt IPP Draft: draft-isaacson-ipp-info-00.txt Can you please update the Agenda document with these titles please. I have not seen the previous Agenda update yet, but I assume it takes a while to get through the pipeline. In case it got lost under way here is a copy: -- Agenda for BOF on Internet Printing Protocol in IETF San Jose Meeting December 12, 1996, 1:00 - 3:00 pm. Introduction (10 mins) History and Requirements (30 mins) - Existing standards for printing - Current user and technology requirements - Proposed Charter for IPP Proposal for the Internet Printing Protocol (30 mins) - Work to date in the Printer Working Group (PWG) - Presentation of the IPP draft document Discussion and Resolution of Issues (if possible) (30 mins) - Needs to coordinate with other IETF projects? - Security Requirements for IPP? - Other issues? Wrap-up (10 mins) - Summary of discussion - List remaining issues to be resolved - Home work assignments - Make recommendation about further progress in IETF Related documents Requirements: draft-wright-ipp-req-00.txt IPP Draft: draft-isaacson-ipp-info-00.txt ------ Thanks, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 25 19:48:09 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18120 for ipp-outgoing; Mon, 25 Nov 1996 19:46:11 -0500 (EST) Date: Mon, 25 Nov 1996 16:46:18 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611260046.QAA01273@woden.eng.sun.com> To: ipp@pwg.org, rdebry@us1.ibm.com Subject: Re: IPP> Re: New Internet-Draft Request (another idea on the protocol X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO If I understood your proposed structure, it does not seem that a standard HTTP reader could find the individual documents within a job, rather a job looks like an opaque application. With my proposal, a print operation appears to a standard HTTP reader to be a series of 1 or more entities, where some entities are opaque applications and others are documents in standard formats. It's hard for me to enumerate advantages. It's more a gut feeling that the best solution is the one which uses an existing structure as much as possible. Then we take advantage of the structure as it develops because a job is built from standard off-the-shelf pieces. In the simplest case a Print job may just consist of a single HTTP entity of document data in a standard format. The Printer then infers the job attributes according to defaulting rules. Bob Herriot > From rdebry@us1.ibm.com Mon Nov 25 15:34:56 1996 > From: rdebry@us1.ibm.com > X400-Originator: rdebry@us1.ibm.com > X400-Recipients: ipp@pwg.org > X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245504000002] > X400-Content-Type: P2-1988 (22) > To: > Subject: IPP> Re: New Internet-Draft Request (another idea on the protocol > Date: Mon, 25 Nov 1996 07:51:11 -0500 > Sender: ipp-owner@pwg.org > Content-Length: 2482 > X-Lines: 60 > > Classification: > Prologue: > Epilogue: > > Bob, I am not familiar enough with the real operation of HTTP protocols to know > whether your idea is a good one or not. I had thought that I could only send > one enitity at a time, which would require leaving the connection open and > turning the line around several times to complete transfer of the message when > sending the document along with the print request. How would this affect > performance? Obviously this is not a concern when pulling the document later. > > What are the advantages of allowing "any" software to read the document data? > Since I only apply the headers when sending the document to be printed I'm not > sure what I gain? In my proposal, the document content itself still has a > standard Mime type. > > ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 11/25/96 05:44 > AM --------------------------- > > ipp-owner @ pwg.org > 11/23/96 12:03 AM > > > To: Scott_Isaacson @ novell.com@internet > cc: ipp @ pwg.org@internet > Subject: Re: New Internet-Draft Request (another idea on the protocol > > > After thinking about the protocol issue some more, it seems like there > are two ways to organize the IPP Job Object in HTTP Protocol, the > current proposal or my proposal described below. > > 1) current proposal: The way proposed in the current document where the > job and all document data is a part of a HTTP single entity-body. > > 2) my proposal: A job is an HTTP document whose top level content type > is multipart/mixed (an existing type) or perhaps multipart/ipp (a new > type and probably a bad idea). In either case, the first entity has a > content type of application/ippjob and contains the job attributes. > Each remaining entity contains a document and they are all standard > MIME types, such as application/PostScript or text/plain. Such a > document could in the future become a multipart/ippdocument with a > document attribute entity and a document content entity if a document > has attribute overrides. The document data entity could also have a > content-type of multipart/alternative (an existing type) if a client > wanted to have several representations of a document, e.g. HTTP and PDF > and a printer supported such. > > > The advantage of my proposal is that the document parts are > conventional MIME documents which any software could read. Only the > application/ippjob and application/ippdocument require special software > to process. > > I hope others will comment on the pros and cons of these two proposals? > > > Bob Herriot > > > From ipp-archive Mon Nov 25 19:48:10 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18075 for ipp-outgoing; Mon, 25 Nov 1996 19:45:48 -0500 (EST) Message-Id: <2.2.32.19961126004401.009546c0@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Nov 1996 16:44:01 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Xerox Comments on IPP Security White Paper Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I am forwarding to you a series of comments made by our local security team. We appreciate the initial effort in writing the White Paper, but think that the subject requires considerable further discussion.=20 Carl-Uno --- Comments on IPP Security White Paper General: =20 Things not covered so far: - How users "discover" printers is not addressed, but important. Security may require that users not see printers for which they have no access when locating printers on the network. Also, directory information about a printer should include the security level required by the printer. - Key management is an important issue, not covered here. - We would like to see scenarios for each of the suggested security levels in order to understand them better. - Scenarios where the document to be printed is fetched by the "printer" from a repository on behalf of the user is not covered. Other general comments: =09 - Use of SSL only gives authentication, but authorization will have to be provided by the printer and some discussion of generic authorization levels will be useful for each scenario. Does level 4 and 5 also assume functionality from level 3 to cover this? - SSL assumes mandatory server authentication, but only optional client authentication. Scenarios where printers must be authenticated at the client are not covered here. -------Start text from the White Paper: As we add security to the IPP model we need to keep in mind the added complexity that security can bring to the system as well as the overhead in terms of network traffic and end-user response time. Running IPP on top of a Secure Sockets (SSL) session provides for message privacy, message integrity, and mutual authentication, but at some added cost. Therefore we might want to consider a model which allows several levels of security, at various cost points, to be configured by the system administrator (from the White Paper): 1) No security: Anyone can submit jobs to the printer. No user ID or password is required. All data transmissions are in the clear. This is the cheapest solution and might well fit into environments not connected to the external Internet where anyone within the environment can freely access any printer. 2) Access Control - no password: The Printer object has an associated Access Control List (ACL), but no password is required to print. All data is sent in the clear. Users are not authenticated. 3) Access Control - password required: The Printer object has an associated ACL which has passwords for each authorized user. Users are not= authenticated. 4) Authenticated access control: The Printer object has an associated ACL. Users identify themselves by sending their public key certificates to the Printer object. Data is still sent in the clear. This scheme would probably be the right level for controlled access within the Intranet. It is still fairly lightweight, but guarantees that only authenticated users can access a given printer or printers. 5) SSL access control: Any communication with the printer is done over an SSL session. Public key certificates are required for both users and Printers. This method would be required where a Printer is made visible outside of the firewall. An SSL session is established, both client and Printer are authenticated, and all data is encrypted before being sent. Message integrity is checked for each transmission. -------End text from the White Paper: Let=92s investigate each of these situations and see how it might impact the IPP specification. - Level 1) No Security In this simple case, the IPP model is used as described. If is required for some reason, for example, to print on a header sheet, the Printer would have to ask for it or it would have to be supplied with the Print request. If the Printer can prompt for we need to define the mechanics of how this works. For this simple case, I=92d suggest that it always be sent in the Print request. - Level 2) Access Control - No Password We believe this case is not different from level 1) from a security-level perspective - names can easily be faked - if simply stating names is adequate for securing rights associated with that name, this has the same level of security as level 1) with the exception of requiring an extra attribute. This case would be much like the previous one, except that is now a required attribute. The printer must either prompt the user for it, or it must be supplied in the Print request. is checked against valid names in the Printers Access Control List (ACL).=20 ACLs usually contain more information than just user names, such as user rights to access services. Perhaps these rights might be grouped under logical printers - still information regarding which logical printer the user is allowed use is important, as well as, what is the user type (such as normal-user, operator, and administrator). Also if there are printers the users are not allowed to use, these might be identified here. In this simple case, we suggest that always be sent in the Print request. - Level 3) Access Control - Password Required This case builds on the previous one. The Printer either prompts for both and (a new attribute), or they are included in the Print request. and are both checked against valid names and passwords in the Printer=92s Access Control List. Again, we would suggest that these flow with the original Print request else we have to define some mechanism to prompt for them. - Level 4) Authenticated Access Control What is the user scenario that requires level 4) but not level 5)? Authenticated access control requires the use of public key certificates. One way to achieve this would be for the original Print request to carry the job-originator=92s public key certificate along with a digitally signed message to verify the identity of the requester.=20 The Printer needs to now authenticate the job-originator=92s certificate,= but this exchange is outside the scope of this protocol. The printer now has enough information to validate that the request really came from the named job-originator. =20 If we can do this exchange differently for different printers, as is proposed, how can we assume the same level of security in each case? If the job-originator name is in the Printer=92s Access Control List then= the Print request is honored. Another, simpler approach to this would assume that the Printer=92s ACL actually contained the public key for each authorized user. The flow could then be something like: Print request ---------------------------------------------- This appraoch may not be secure enough even for intranets: an intruder can capture the digital signature, and send it along with the job originator and submit any job. ("man-in-middle" attack, combined with "replay" attack) Since the printer already has john doe=92s public key, it can decrypt the message hash, compare it, and validate that it came from john doe. (anyone else sending it would have to have john doe=92s private key). This would not be an unreasonable approach in a corporate intranet. Getting user=92s public keys into the ACL is outside of the scope of this specification. - Level 5) SSL Controlled Access When a print service provider accepts print requests from outside of the firewall, it is critical that mutual authentication and full message privacy and integrity be provided. If I send a print job to something advertised as a "Kinko=92s Print shop", I=92d like to be sure that that is really where= the print job is going. Likewise, for billing purposes, the print provider must guarantee that the requester is who he says he is. This level of security seems to require full use of an SSL session. In this case the client initiates a secure session with the print provider. Secure browsers use a well know port for an SSL session, we would have to do the same for IPP. During the initiation of the SSL session, the client and print provider agree on a protocol version, exchange public key certificates, select encryption algorithms, and use public key encryption algorithms to generate shared secrets. Now the IPP protocol runs over a secure session. Clearly, this is a lot of overhead, but seems to be required in this particular environment.=20 Authorization levels is assumed to be part of this, but is not covered by= SSL. Non-repudiation (proof of origin, proof of receipt, proof of submission and proof of delivery) is not covered, but may not be required by the user scenarios under consideration. Recommendation Based on the above, we would like to recommend the addition of two= attributes =B7 =B7 The client would always send and would send or based on the type of security established in the system when it was configured. SSL would only be used in Internet configurations. We question whether levels 2) and 4) are really needed and meaningful, unless some convincing scenarios can be presented that actually require= them. ----- Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Mon Nov 25 19:58:06 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA18465 for ipp-outgoing; Mon, 25 Nov 1996 19:58:04 -0500 (EST) Message-Id: Date: Mon, 25 Nov 96 19:58 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: IPP> Correction on the location of the new Internet Draft documents Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Scott recently announced: > I also put the following files in ftp://ftp.pwg.org/pub/ipp/drafts > > draft-isaacson-ipp-info-00.txt just now submitted to internet-drafts@ietf.org > ipp94.doc same as draft-isaacson-ipp-info-00.txt w/line numbers > ipp94.pdf " " PDF file > ipp94rev.doc rev marks against ipp93 > ipp94rev.pdf " " PDF file Please note that the correct directory root for these documents is: ftp://ftp.pwg.org/pub/pwg/ipp/drafts Congrats to Scott for his efforts! ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03015-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From ipp-archive Mon Nov 25 20:03:06 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA18639 for ipp-outgoing; Mon, 25 Nov 1996 20:00:10 -0500 (EST) Date: Mon, 25 Nov 1996 16:56:44 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611260056.QAA01289@woden.eng.sun.com> To: hastings@cp10.es.xerox.com Subject: Re: IPP> Re: New Internet-Draft Request [ job-state-reasons being empty] Cc: ipp@pwg.org X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I prefer that we keep this as an issue. Although I understand your reasons for not wanting empty values, there may be good reason for attributes whose values are a set of 0 or more values. The issue is that you would like to represent the NULL Set by a set having a special member which cannot coexist with other members. This solution may add more complexity than we are removing. Bob Herriot > From hastings@cp10.es.xerox.com Mon Nov 25 16:42:21 1996 > X-Sender: hastings@zazen > X-Mailer: Windows Eudora Pro Version 2.1.2 > Mime-Version: 1.0 > Date: Sun, 24 Nov 1996 08:27:08 PST > To: robert.herriot@Eng (Robert Herriot) > From: Tom Hastings > Subject: IPP> Re: New Internet-Draft Request [ job-state-reasons being empty] > Cc: Scott_Isaacson@novell.com, ipp@pwg.org > Sender: ipp-owner@pwg.org > X-Lines: 18 > > At 23:54 11/22/96 PST, Robert Herriot wrote: > >More comments on Ipp93rev.doc > > > >line 1347: the syntax for job state reasons should be (#type2Enum) because > there can be 0 reasons. > > > > While I agree that job-state-reasons has a natural interpretation > when there are no values, namely that there are no reasons associated > with the current job state (and the semantics say that no reasons is > valid), Carl-Uno and I think that it is simpler and more consisten to > always require a value for job, printer (and Job template) attributes. > So we prefer to add a "none" value to job-state-reasons and keep the > syntax as (1#type2Enub). Then every attribute that is a list, must > have at lease one member. Ok? > > Tom (and Carl-Uno) > > From ipp-archive Mon Nov 25 21:23:07 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA18881 for ipp-outgoing; Mon, 25 Nov 1996 21:22:57 -0500 (EST) Date: Mon, 25 Nov 1996 18:22:57 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611260222.SAA01390@woden.eng.sun.com> To: ipp@pwg.org, Scott_Isaacson@novell.com Subject: Re: IPP> IPP Internet-Draft X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Issue on line 1386: 2-sided-long-edge and 2-sided-short-edge work the same for portrait or landscape. That is one of the nice things about the concepts. On the other hand head-to-toe is tumble in portrait but duplex in landscape. Head-to-head, likewise switches. Since the orientation attribute is for an entire document, I am not sure that reverse-landscape has any value. Bob Herriot From ipp-archive Mon Nov 25 21:43:08 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA19063 for ipp-outgoing; Mon, 25 Nov 1996 21:39:11 -0500 (EST) Date: Mon, 25 Nov 1996 18:39:19 -0800 From: robert.herriot@Eng.Sun.COM (Robert Herriot) Message-Id: <199611260239.SAA01457@woden.eng.sun.com> To: ipp@pwg.org, Scott_Isaacson@novell.com Subject: Re: IPP> IPP Internet-Draft X-Sun-Charset: US-ASCII Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Great Job Scott! I found a few typos: MS Word thinks that 'implementor' should be changed to 'implementer'. in the table above line 928, it says ... is r are returned:eturned. The word returned is split and duplicated A couple of lines further down in the same table cell: For each J position-in-list. ob URL ... The word Job seems to have been split. A couple of lines further down in the same table cell: ... and andposition An extra 'and' A couple of lines further down in the same table cell: change 'and end user' to 'an end user' A couple of lines further down in the same table cell: ... inter esponse,spersed. Delete 'esponse'. Above line 969 in type2Enum cell: change 'cancan' to 'can', change 'TBDbyvalues' to 'values', change 'anytimereviewed' to 'reviewed', change 'approvaal' to 'approval' A couple of lines further down in the next table cell: change 'namvalues' to 'values'. line 1071: in table cell for processing: fix 'enginthe'. I not sure what should be here. line 1993: change 'atttribute' to 'attribute' From ipp-archive Tue Nov 26 10:28:22 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19766 for ipp-outgoing; Tue, 26 Nov 1996 10:25:47 -0500 (EST) Message-Id: <199611261526.AA04369@interlock.lexmark.com> To: "ipp%pwg.org" From: Don Wright Date: 26 Nov 96 10:25:06 EST Subject: IPP> BOF Presentation on Requirements Mime-Version: 1.0 Content-Type: Text/Plain Sender: ipp-owner@pwg.org Precedence: first-class Status: RO I have created a three page presentation which I will use at the IETF meeting on Dec 12th. I have placed a PDF version on the ftp server as: ftp://ftp.pwg.org/pub/pwg/ipp/Present/ipp-req.pdf Please take a look at this and let me know if anyone has any problems with the form or content. Tom Hastings: I have not included any details on the LPD problems as I was waiting for the info you said you had or could get. Where does that stand?? Don ************************************************************* * Don Wright (don@lexmark.com) Lexmark International * * Manager Strategic Alliances * * 740 New Circle Rd Phone: 606-232-4808 * * Lexington, KY 40511 Fax: 606-232-6740 * ************************************************************* From ipp-archive Tue Nov 26 12:23:17 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA20046 for ipp-outgoing; Tue, 26 Nov 1996 12:23:01 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 26 Nov 1996 10:19:49 -0700 From: "Scott A. Isaacson" To: robert.herriot@Eng.Sun.COM, ipp@pwg.org Subject: Re: IPP> IPP Internet-Draft -Reply Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Bob, Thanks for finding the typos. From the line numbers it looks like you were looking in ipp94rev.doc. This time in order to generate the line numbers, I did a document compare of ipp94.doc against ipp93.doc to generate ipp94rev.doc. It looks like it did pretty well, except it introduced some weird stuff in the rev version that was not in the original (ipp94.doc). I can't find these same errors in ipp94.doc. I have fixed the misspelled attribute though! Thanks. Scott >>> Robert Herriot 11/25/96 07:39pm >>> Great Job Scott! I found a few typos: MS Word thinks that 'implementor' should be changed to 'implementer'. in the table above line 928, it says ... is r are returned:eturned. The word returned is split and duplicated A couple of lines further down in the same table cell: For each J position-in-list. ob URL ... The word Job seems to have been split. A couple of lines further down in the same table cell: ... and andposition An extra 'and' A couple of lines further down in the same table cell: change 'and end user' to 'an end user' A couple of lines further down in the same table cell: ... inter esponse,spersed. Delete 'esponse'. Above line 969 in type2Enum cell: change 'cancan' to 'can', change 'TBDbyvalues' to 'values', change 'anytimereviewed' to 'reviewed', change 'approvaal' to 'approval' A couple of lines further down in the next table cell: change 'namvalues' to 'values'. line 1071: in table cell for processing: fix 'enginthe'. I not sure what should be here. line 1993: change 'atttribute' to 'attribute' From ipp-archive Tue Nov 26 14:53:18 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20362 for ipp-outgoing; Tue, 26 Nov 1996 14:52:37 -0500 (EST) Message-Id: Date: Tue, 26 Nov 96 14:53 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: IPP> FWD: emerging directory schema standards? Sender: ipp-owner@pwg.org Precedence: first-class Status: RO This message was just posted to the LDAP mailing list. I thought some of the folks on the IPP list might find this a bit interesting, given that we expect LDAP to play a critical role in providing the vehicle for locating printers. ...jay ----- Begin Included Message ----- >From terminator.rs.itd.umich.edu!owner-ldap Tue Nov 26 12:40:09 1996 X-Sender: snewton@oac3.hsc.uth.tmc.edu Date: Tue, 26 Nov 1996 09:17:46 -0600 To: Rob Winters , ldap@umich.edu From: "Steven E. Newton" Subject: Re: emerging directory schema standards? Mime-Version: 1.0 At 02:54 PM 11/25/96 -0500, you wrote: >I'd appreciate being pointed to any existing or proposed standards, >white papers, etc, that discuss the standardization of directory >schema for Internet directories. > Well, unfortunately, IMHO, the LDAP people didn't fully do their homework as far as directory schema go. The x.500 people did, however, and there are several RFCs related to directory schema. I would suggest rfcs 1274, 1617, and 1803 to start with. But, I doubt the various vendors will pay attention to them. Actually, it seems, and I regret this direction very much, that the vendors seem to want to go with a directory server that is NOT an X.500 dsa, but something like SLAPD. Given the amount of traffic on this list asking about how to make ACL and DNs and such work 'right' with SLAPD, I think most of them would actually do just as well to get a real DSA. One particular failing in SLAPD is the missing functionality of shadowing, referrals, replication and the like. s -- + + + + + | snewton@oac.hsc.uth.tmc.edu | Nobody else speaks for me, Uh oh, no Boom. | and I speak for no one else. | http://www.uth.tmc.edu/~snewton/ | + + + + + + ----- End Included Message ----- From ipp-archive Tue Nov 26 14:58:19 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA20544 for ipp-outgoing; Tue, 26 Nov 1996 14:54:14 -0500 (EST) Message-Id: Date: Tue, 26 Nov 96 14:54 EST From: jkm@underscore.com (JK Martin) To: ipp@pwg.org Subject: IPP> FWD: Re: emerging directory schema standards? Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Here's a qualified reply to the previously forwarded message, this time from a person actively involved in the LDAP effort. ...jay ----- Begin Included Message ----- >From terminator.rs.itd.umich.edu!owner-ldap Tue Nov 26 13:43:39 1996 From: Mark Wahl To: "Steven E. Newton" cc: Rob Winters , ldap@umich.edu Subject: Re: emerging directory schema standards? Date: Tue, 26 Nov 1996 09:51:11 -0600 > Well, unfortunately, IMHO, the LDAP people didn't fully do their homework > as far as directory schema go. The x.500 people did, however, and there As an access protocol, LDAP does not define a schema, since there is no single fixed schema which would meet all the planned applications of Internet directory services. However you may wish to take a look at the Internet Draft , in which LDAP representations of all the attributes and object classes of X.520(1993), X.521(1993) and RFC 1274 are specified. Those interested in participating in schema issues should consider joining the IETF IDS working group mailing list, to which one can be subscribed by contacting ietf-ids-request@umich.edu. Amongst their activities, they are working on a draft "A Common Schema for the Internet White Pages Service", . The IETF Integrated Directory Services (IDS) Working Group proposes to establish a specification for a simple Internet white pages service. To facilitate this effort it would be helpful to have a common schema used by the various white page servers. This document is designed to specify the basic set of attributes to be used for a white page entry for a person. This schema does not describe how to represent other objects in the White page service. It does describe how new objects can be defined and registered. This schema is independent of implementations of the White Page service. Hope this helps, Mark Wahl, Enterprise Directory Integration Critical Angle Incorporated ----- End Included Message ----- From ipp-archive Wed Nov 27 15:21:52 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id PAA24481 for ipp-outgoing; Wed, 27 Nov 1996 15:20:29 -0500 (EST) Message-Id: <2.2.32.19961127182355.0095bebc@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Nov 1996 10:23:55 PST To: ipp@pwg.org From: Carl-Uno Manros Subject: IPP> Re: IETF BOF PING Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Larry Masinter (IETF HTTP chair) has confirmed his attendence at our BOF. Carl-Uno >Return-Path: >To: cmanros@cp10.es.xerox.com >Subject: Re: New Drafts for IPP available >Sender: Larry Masinter >From: Larry Masinter >Date: Wed, 27 Nov 1996 03:40:09 PST > >Carl-Uno, > >I'm planning on being at the BOF on THursday, 1-3. > >You probably should stay for the IETF-FAX BOF on Friday, don't you >think? > >I'm trying to recover from jet lag and getting way behind on >mail. I'll see if I can review the IPP drafts this week, though. > >Larry > > From ipp-archive Wed Nov 27 18:21:54 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25361 for ipp-outgoing; Wed, 27 Nov 1996 18:20:28 -0500 (EST) Message-Id: <9611272316.AA29226@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Nov 1996 15:14:14 PST To: ipp@pwg.org From: Tom Hastings Subject: IPP> FWD: draft-isaacson-ipp-info-00.txt comments. Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Oops! We forgot to put the pwg@pwg.org as a DL for comments on the IPP Internet draft. So the four authors will be receiving comments, since that was the only DL listed on the Internet Draft. When we do, we should forward to the ipp DL. So here's the first such comment that we received. We should draft some answers. Tom >Return-Path: >To: scott_isaacson@novell.com, hastings@cp10.es.xerox.com, > robert.herriot@eng.sun.com, debry@vnet.ibm.com >Cc: abochann@cisco.com >Subject: draft-isaacson-ipp-info-00.txt comments. >Date: Wed, 27 Nov 1996 12:04:53 PST >From: Alex Bochannek > >Hi! > >I just stumbled across draft-isaacson-ipp-info-00.txt and have to tell >you that I am very excited about it. While printing administration >isn't in my job description, I do work together with people who have >to fight this beast and I think everybody who ever worked in an IS >environment had to at one point or another. > >So, anyway, as I said, I am really excited about your work and hope >that it will be implemented widely and quickly. I did notice though >that noone from Microsoft or Apple contributed. > >A few quick comments: > >- I don't see any references to fan-fold paper anywhere. > >- It appears there is currently no suppurt fo accounting. One can > certainly argue that this is a function of security which you say > will be addressed later. > >- How do you plan to support color calibration and other features like > what is provided through PPD files? > >- I suspect that PostScript printing control (like spooling, status > queries, etc.) are not supported as part of the PostScript > Content-Type, right? It probably should be spelled out. > >Thanks. > >-- >Alex Bochannek Phone & Fax : +1 408 526 51 91 >Senior Network Analyst Pager : +1 408 485 90 92 >Engineering Services Alpha Pager : (800) 225-0256 PIN 104536 >Cisco Systems, Inc. Email : abochannek@cisco.com >170 West Tasman Drive, Bldg. E Pager Email : abochannek@beeper.cisco.com >San Jose, CA 95134-1706, USA > > From ipp-archive Wed Nov 27 19:04:20 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id SAA25880 for ipp-outgoing; Wed, 27 Nov 1996 18:57:54 -0500 (EST) Message-Id: <2.2.32.19961127234452.00994994@garfield> X-Sender: cmanros@garfield X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Nov 1996 15:44:52 PST To: abochann@cisco.com From: Carl-Uno Manros Subject: IPP> RE: draft-isaacson-ipp-info-00.txt Cc: ipp@pwg.org Sender: ipp-owner@pwg.org Precedence: first-class Status: RO Alex, thanks for your comments and suggestions concerning this draft. There is another related draft describing the requirements for this project under the name: draft-wright-ipp-req-00.txt We are scheduled to have a BOF session in San Jose on Thursday, December 12 at 1:00 - 3:00 pm. If you can make it there, you will meet the authors and various other people who have been involved with the project so far. We are trying to get this established as a formal WG soon after the San Jose meeting. We already have a mailing list set up and you are welcome to join it, see details below. The following text is a draft proposal to the IETF for our WG charter. It should contain all the info you need to get started. --- IETF Internet Printing Protocol (ipp) WG Chair(s): Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor: TBD Mailing List Information: General Discussion: To Subscribe: Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Editor: Scott Isaacson Description of Working Group: Internet printing involves using Internet technologies and services to find networked resources, such as printers, and then submit jobs using those resources. The goal of this working group is to define a new application level distributed printing protocol as well as defining naming and service registration attributes for printing. The protocol shall support a global, distributed environment where print service users (clients, applications, drivers, etc.) cooperate and interact with print service providers (servers, printers, gateways, etc.). The working group will leverage existing (and emerging) technologies for: authentication, authorization, privacy, and commercial transactions. For location of printers, the working group will leverage existing standards for directories. The working group shall strive to coordinate its activities with other printing-related standards bodies. The new job submission protocol should strive not to preclude any types of output devices (e.g., fax, printer, gateway). Also, the working group will define extensibility paths to maximize interoperability and minimize conflict. The Internet Printing Protocol will be designed to make use of Web browsers, HTTP, and LDAP for directory look-ups. The Internet Printing Protocol is intended to supplant RFC 1179 'Line Printer Daemon Protocol' as the preferred printing protocol. LPR/LPD was designed a long time ago with line printers in mind and does not fit with current needs. Deliverables and Milestones: Done - Mailing list and archive November 1996 - Submit first set of Internet-Drafts December 1996 - BOF in IETF meeting in San Jose, CA, USA March 1997 - Submit Internet-Drafts April 1997 - Review of specification in IETF meeting in Memphis, TN, USA May 1997 - At least 2 implemented prototypes May 1997 - Submit document(s) to the IESG for Proposed Standard Internet-Drafts: IPP-requirements: draft-wright-ipp-req-00.txt IPP-draft: draft-isaacson-ipp-info-00.txt ---- Regards, Carl-Uno Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com From ipp-archive Wed Nov 27 19:51:54 1996 Return-Path: ipp-owner Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA26767 for ipp-outgoing; Wed, 27 Nov 1996 19:51:30 -0500 (EST) Message-Id: <199611280051.QAA10164@hubbub.cisco.com> To: Carl-Uno Manros Cc: ipp@pwg.org Subject: IPP> Re: draft-isaacson-ipp-info-00.txt In-reply-to: Your message of "Wed, 27 Nov 96 15:44:52 PST." <2.2.32.19961127234452.00994994@garfield> Date: Wed, 27 Nov 96 16:51:11 PST From: Alex Bochannek Sender: ipp-owner@pwg.org Precedence: first-class Status: RO OK, I subscribed. Just hope I won't get inundated with mail ;-) And for the record, my interest in printing has (almost) nothing to do with my work at Cisco. In case people haven't seen my comments, here we go: - I don't see any references to fan-fold paper anywhere. - It appears there is currently no suppurt fo accounting. One can certainly argue that this is a function of security which you say will be addressed later. - How do you plan to support color calibration and other features like what is provided through PPD files? - I suspect that PostScript printing control (like spooling, status queries, etc.) are not supported as part of the PostScript Content-Type, right? It probably should be spelled out. -- Alex Bochannek Phone & Fax : +1 408 526 51 91 Senior Network Analyst Pager : +1 408 485 90 92 Engineering Services Alpha Pager : (800) 225-0256 PIN 104536 Cisco Systems, Inc. Email : abochannek@cisco.com 170 West Tasman Drive, Bldg. E Pager Email : abochannek@beeper.cisco.com San Jose, CA 95134-1706, USA