From Stuart.Rowley at kyocera.com Wed Jul 1 12:12:28 1998 From: Stuart.Rowley at kyocera.com (Stuart Rowley) Date: Wed May 6 13:59:58 2009 Subject: JMP> How to compile Job MIB with OpenView Message-ID: <0004D502.@kyocera.com> Job MIBers, How can the Job MIB be compiled with HP OpenView? In the MIB document on page 18 it says: "This MIB, like the Printer MIB, is written following the subset of SMIv2 that can be supported by SMIv1 and SNMPv1 implementations." But while OpenView can compile the Printer MIB, it chokes on the Job MIB. Any ideas why OpenView will not compile the Job MIB? Thanks, Stuart --------------------------------------------------------------------- Stuart Rowley Kyocera Electronics, Inc. Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 stuart.rowley@kyocera.com Lafayette, CA 94549 925 299-7206 Fax: 925 299-2489 --------------------------------------------------------------------- From rbergma at dpc.com Wed Jul 1 12:22:30 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> How to compile Job MIB with OpenView In-Reply-To: <0004D502.@kyocera.com> Message-ID: Stuart, When I tried to compile a private MIB on Open View it didn't understand "enterprises". I had to add the following: internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } I don't know if all are required, as I added all three lines and didn't try to remove any after it was successful. Note that I have a four year old version of Open View, so your results may be different. Good luck :-) Ron Bergman Dataproducts Corp. On Wed, 1 Jul 1998, Stuart Rowley wrote: > Job MIBers, > > How can the Job MIB be compiled with HP OpenView? In the MIB document on > page 18 it says: > "This MIB, like the Printer MIB, is written following the subset of SMIv2 > that can be supported by SMIv1 and SNMPv1 implementations." > But while OpenView can compile the Printer MIB, it chokes on the Job MIB. > > Any ideas why OpenView will not compile the Job MIB? > > Thanks, > > Stuart > > --------------------------------------------------------------------- > Stuart Rowley Kyocera Electronics, Inc. > Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 > stuart.rowley@kyocera.com Lafayette, CA 94549 > 925 299-7206 Fax: 925 299-2489 > --------------------------------------------------------------------- > From hastings at cp10.es.xerox.com Thu Jul 2 01:33:46 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 13:59:58 2009 Subject: JMP> White paper - proposal to add multi-function activity attributes Message-ID: <3.0.5.32.19980701223346.00a11ba0@garfield> I've uploaded a white paper that proposes about 30 attributes that are designed to be useful for multi-function systems, including printing, scaning, faxIn, faxOut, etc. It also gives more detailed accounting, as each different combination of accounting data is collected in a separate row, called an "activity". ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jmp-activity-accounting-01.doc ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jmp-activity-accounting-01.pdf If approved, these attributes would be registered with the PWG as Job Monitoring MIB attributes. I propose to discuss these ideas at the JMP MIB meeting on Friday, July 10. I'll bring copies to the meeting. Its 19 pages long. Thanks, Tom From hastings at cp10.es.xerox.com Mon Jul 27 23:13:15 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: job mib feedback In-Reply-To: <199807271855.OAA19942@spot.cs.utk.edu> Message-ID: <3.0.5.32.19980727201315.017b3430@garfield> At 11:55 07/27/98 PDT, Keith Moore wrote: >Tom & Chris, > >The job mib was on the agenda for the IESG's Jul 16 telechat. >It was held up because of problems with the specification. >To wit: > >> It is on this weeks telechat agenda as a WG subission to go >> out as INFORMATIONAL RFC. Number 3 below is real serious. >> >> 1.I get 15 warnings about unused TCs. >> That is acceptable... but are they used elsewere? No, they are only used in this MIB. But they only appear as comments in the JmAttributeTypeTC. We have the case of a TC "using" the 15 TCs. We could add dummy used of these TCs, to make the warnings go away, but the "That is acceptable" sound like we don't really have to do that. >> In other words do you need to keep them? Yes, because an implementation does use the values. These TCs are the values of attributes that are of type enum. Attributes can also have integer values that count and/or octet strings that are keywords or text strings. The Job MIB is trying to have job attributes like IPP has Job attributes. >> There are strange TCs among them, for example the >> JmBooleanTC, which to me does not look like a Boolean >> since it can have 3 values!!?? >> And we have a standard TC for a boolean: TruthValue in RFC1903 The JmBooleanTC does have three values. The third value is 'unknown'. That is used for the case when the agent doean't know whether the value is 'true' or 'false'. >> >> 2.The use of MUST, MAY, SHOULD, SHALL, MUST NOT and such >> seems completely nonsense the me. It looks as if they >> capitalized evry occurence of such words. There are 5 or so MUSTs and a large number of SHALLs. Should we change the 5 MUSTs to SHALL to be consistent? There are a few sentences that have SHALL which are descriptive sentences, rather than describing an action by the agent or the NMS (management application). Those descriptive sentences should have the SHALL removed. However, shouldn't any sentence that has the agent or the NMS (management application) as the subject of the sentence have a SHALL, if that action is required for a conforming agent or management application? >> >> 3.The structure of the MIB is totaly "non-SNMP" like. I suspect that you are referring to the attribute mechanism which like a 'dictionary'. We have found that for Printers and Jobs, that the features that various implementors implement vary so much that we couldn't have groups of objects. Many objects in a group would return 'empty strings', since there was no value to go with them. Most implementations need to be able to pick and choose between the various attributes. Some implement two-sided printing, some implement stapling, some implement job names, some implement document names, some implement multiple documents per job, some count sheets, some count impressions, some can only count octets, etc. etc. >> It is the 2nd wierdest MIB I have ever seen. >> I have difficulty saying go ahead and publish. >> But... it is work of the PWG which is outside of the >> IETF, right? So not sure what we can/should do. >> I would certainly NOT let this thing go on the standards >> track. See the comments from David Perkins of over a year ago (attached) which did not object to the attribute mechanism, though he did suggest that we make the attributes be two tables, instead of one. We kept the table as one, since there are some attributes that have both an integer and a string value. We took account of all his other comments. The area directors rejected putting the Job MIB on the standards track a year ago on the grounds that it was an application, not something that managed the network. There was no concern about the attribute mechanism mentioned then. >> >> 4.Several references may need to be changed/updated. No doubt. This document is over five months old. Should we attempt to determine which ones are out of date? > >My understanding was that one of the O&M ADs was supposed to >contact you about this, to better understand how the problems >might be fixed. This might have been delayed since many of >the IESG folks were at the ISOC conference in Geneva last week. > >Keith > > >Reply-To: >From: "David T. Perkins" >To: , , >Subject: Review of Job Monitoring MIB >Date: Fri, 27 Jun 1997 01:18:07 PDT >X-Msmail-Priority: Normal >X-Mailer: Microsoft Internet Mail 4.70.1155 > >HI > >I finished looking over the document. (I spent about 5 hours) >In general, the objects that are defined in the MIB module are >relatively few in number and easy to understand. However, the >document has some problems and the MIB module has some problems >that can be easily solved without changing the semantics of >the MIB objects or losing any capabilities. > >There is one change that would affect any current implementations >that I strongly suggest that you do. Table jmAttributeTable has >three accessible columnar objects. The first tells you the "type" >(either integer, octet, or both) of the value of the attribute. >The second two columns are the attribute's value. I suggest that >instead of this single table, that you have two tables. Each table >would have a single accessible column. The first table would contain >integer valued attributes, and the second table would contain >octet string valued attributes. > >On the document itself, none of the cross references seemed valid! >In general you have way too much text in the descriptions for the >textual conventions and objects that should be in the text that >comes before the MIB module. > >The MIB and the agent don't "instrument" a managed device. An SNMP >agent provided access to instrumentation. Thus, many times throughout >the document were I saw sentences like the following, it would cause >me to grit my teeth: > An agent is the network entity that accepts SNMP requests from a > monitor and implements the Job Monitoring MIB by instrumenting > a server or a device. >This is not correct! A correction of the above text is the following >text: > An agent is the network entity that accepts SNMP requests from a > monitor (an SNMP management application) and provides access to the > instrumentation for managing jobs modeled by the management objects > defined in the Job Monitoring MIB module. > >The reason why the original text is not correct is that the instrumentation >is independent of the mechanism used to access the management information. >That is, the instrumentation could have a local interface so that a >program could be run on the server or device that displayed management >information on a local console. > >On your configurations of printers-clients-servers, you specify three >and say that configuration 2 is not the design center for the document. >I don't understand. I think that configuration 2 would be the most common >and think that configuration 3 is unworkable. (How would configuration 3 >work if there were a pool of printers?) > >The approach to specifying conformance is quite inappropriate. SMIv2 has >a well defined mechanism which is not being used properly. Yes you have >a module compliance specification, but you also have compliance >specifications all through the MIB module in ASN.1 comments. You need to >remove the ASN.1 comments with compliance specifications. In the text >of the document, you simply specify the compliance specifications by >referencing the one or more module compliance specifications in the >MIB module! >The conformances for management applications is sort of silly. You >basically say that they cannot have bugs and must correctly implement >and use SNMP. This is silly and should be removed. > >The module has a problem with all the objects that have type of OCTET >STRING. >You really need to enforce a code-point mapping. Consider a management >application. What are they to do with the values? Do they try to figure >out the encoding, or ask the user of the application for a hint, or what? > >The text of section 8.1 is invalid. No other definition of MIB objects >can cause the access for MIB objects in the current module to change. > >The text of section 9 is bogus to the max. The "normal SNMP practice" that >you describe does not exist. What you really want to say is something like >the following: > > 9. Values for Objects > SNMP requires that if an object cannot be implemented because its values > cannot be accessed, then a compliant agent must return an SNMP error in > SNMPv1 or an exception value in SNMPv2. This MIB has been designed so >that > all objects can be implemented. In general, values for objects have been > chosen so that a management application will be able to determine if > a useful value is available for an object. The approach is to define > the value 'unknown(2)' for enums, the value '-2' for integers, and the > zero length string for octet strings to mean that a useful value is > not available for an object. > >Section 10 should be called just "Notifications" and not "Notifications >and Traps". The first sentence should be "this MIB module does not specify >any notifications." > >At the beginning of the MIB module, you did a good thing by providing the >RFC editor with instructions for what to do when the document is published. >However, the details were not quite correct. You cannot have the definition >"temp OBJECT IDENTIFIER ::= { experimental 54 }" before the module identity >construct. You should delete the definition "temp OBJECT IDENTIFIER ::= { >experimental 54 }, and specify the value for jobmonMIB as >{ experimental 54 105 }, and fix the editing instructions in the comment >before the module compliance. > >Throughout the MIB module the text references pages and items in the >reference section. This is a really bad thing to do, since these references >will have not meaning after the MIB module is extracted from the document! >Get rid of them. In the description for the module identity, create >short labels for items found in the references section of the document, >and use those labels in text in the MIB module. For example, to reference >RFC 1213, you might add the following in the description: > [MIB-2] - RFC 1213 >And specify "[MIB-2]" in your other descriptions, instead of [5] from your >references section of the document. > >Add the WG email and WEB site in the CONTACT-INFO description text. I'm >sure >that you do not want to be contacted by every university student that >was assigned a project to write a management application that uses the >job monitoring MIB. > >All the ASN.1 comments for each enumerated value should be in the >description >text for the TC. Thus, a TC definition should look something like the >following: > MyTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "bla..bla..bla.. > The values are: > v1(1)...bla-bla-bla > v2(2)...bla-bla-bla > ... > vn(n)...bla-bla-bla" > SYNTAX INTEGER {v1(1), v2(2), ...vn(n)} > >In general, you provide text in the descriptions for the TCs and the values >of the TCs that should go in the text of the document. > >Figure 4 for TC JmJobState is messed up (due to formatting problems?). > >The description for TC jmAttributeTypeTC is quite bogus. It is not longer >needed, if you follow my suggestion above. > >The indexing for tables jmGeneralTable and jmJobTable is illegal. (just >because RMON-2 and a could other MIBs did something like this does not >make it legal.) > >Several of your objects need a units clause, such as >jmGeneralJobPersistence. > >I believe that the "helpful note" in the description for row jmJobIdEntry >will cause more confusion than provide help. > >You have a typo for the RFC number of the printer MIB. It should be >RFC 1759 and not RFC 1579. > >That's it for now. >Regards, >/david t. perkins > > > From hastings at cp10.es.xerox.com Tue Jul 28 02:32:50 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: job mib feedback [more explanation about attributes] In-Reply-To: <199807271855.OAA19942@spot.cs.utk.edu> Message-ID: <3.0.5.32.19980727233250.00bf91c0@garfield> At 11:55 07/27/98 PDT, Keith Moore wrote: snip ... >> 3.The structure of the MIB is totaly "non-SNMP" like. >> It is the 2nd wierdest MIB I have ever seen. >> I have difficulty saying go ahead and publish. >> But... it is work of the PWG which is outside of the >> IETF, right? So not sure what we can/should do. >> I would certainly NOT let this thing go on the standards >> track. This is a more complete explanation of the reason that we advanced the attribute structure in the PWG job monitoring MIB. Its been prototyped for over a year. The reason for the new structure is that we found in doing the Printer MIB (RFC 1759) that printers vary from model to model and vendor to vendor that attempting to combine objects into a group for perpurposes of conformance was too difficult. One implementation would only have one or two items in a group, and so would forced with the decision to implement the whole group, returning empty strings or other(1) enums for most of the objects or omit the group entirely. So we invented the attribute concept which is conceptually like most job submission protocols, such as IPP, DPA, or LPD, in that an implementation of a job need only support the attributes that the device or server contains. Furthermore, each job submission could omit any attributes that were not needed for that job. The idea is that a TC defines the enum values that identify each attribute. That enum is used as a index into the attribute table. Thus an NMS can either access the attribute directly with a Get operation specifying the index enum value for that attribute or can "harvest" a bunch of attributes doing GetNext, skipping over the unimplemented or unsupplied attributes for that job. We also added one final index to allow an attribute to have more than one value (integer or octet string), as in most job submission protocols. So, while the Job MIB doesn't look like other MIBs, its attribute concept reflects the semantics of jobs that have attributes. Also the indexing, Get, and GetNext semantics seems to lend themselves well for representing jobs which vary so much between product implementations and between each job submission with a particular product. Does that make sense? Thanks, Tom From hastings at cp10.es.xerox.com Tue Jul 28 03:38:22 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: job mib feedback [more explanation about attributes] In-Reply-To: <3.0.5.32.19980727233250.00bf91c0@garfield> References: <199807271855.OAA19942@spot.cs.utk.edu> Message-ID: <3.0.5.32.19980728003822.02072c00@garfield> At 11:55 07/27/98 PDT, Keith Moore wrote: snip ... >> 3.The structure of the MIB is totaly "non-SNMP" like. >> It is the 2nd wierdest MIB I have ever seen. >> I have difficulty saying go ahead and publish. >> But... it is work of the PWG which is outside of the >> IETF, right? So not sure what we can/should do. >> I would certainly NOT let this thing go on the standards >> track. To see the variations of job submission protocols for representing job objects, we mapped the attributes of 10 print job submission protocols to the Job Monitoring MIB. Please refer to draft-ietf-printmib-job-protomap-03.txt. It shows that some job submission protocols have very few attributes and some have a lot of attributes. Many printers have to support more than one job submission protocol. The Job MIB is attempting to allow a printer that supports multiple job submission protocols to support them with a single MIB. Thus the Job MIB allows a management application to query jobs that were submitted using different job submission protocol, but that are all in the same "queue" for the printer, and get their job attributes. Thanks, Tom From rbergma at dpc.com Wed Aug 12 15:51:23 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Anyone for an Interoperability Test? Message-ID: There has been some interest in a Job Monitoring MIB interoperability test. Please respond if you have an interest and when will you be ready to test. Ron Bergman Dataproducts Corp. From Angelo.Caruso at usa.xerox.com Thu Aug 13 14:13:09 1998 From: Angelo.Caruso at usa.xerox.com (Caruso, Angelo ) Date: Wed May 6 13:59:58 2009 Subject: JMP> Anyone for an Interoperability Test? Message-ID: <576F850CF0D5D111A38100805FC7FA0E1A84A8@usa0111ms2.eng.mc.xerox.com> Gee, it's awfully quiet out there. Who expressed interest in an interop test? Speaking for the Xerox Channels Group, we do not have anything ready for an interop test in the next couple of months. Thanks, Angelo -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Wednesday, August 12, 1998 3:51 PM To: jmp@pwg.org Subject: JMP> Anyone for an Interoperability Test? There has been some interest in a Job Monitoring MIB interoperability test. Please respond if you have an interest and when will you be ready to test. Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Thu Aug 13 19:56:35 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 13:59:58 2009 Subject: JMP> Anyone for an Interoperability Test? Message-ID: <5030100024539168000002L082*@MHS> IBM is definitely interested in a Job MIB interop test. The 2 month time frame is OK with us. We would need some time to determine how to test such a dynamic environment, anyway. One thing I think we might want to do is arrange it as an interoperability demonstration rather than a full compliance test. In this context, we would be willing to supply a version of our NT Port monitor using the Job MIB as a client that would interoperate with anyone's printer. However, we would emphasize, our client would not be considered a compliance test tool. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 08/13/98 05:49:09 PM Please respond to jmp-owner@pwg.org To: jmp@pwg.org, rbergma@dpc.com cc: Subject: RE: JMP> Anyone for an Interoperability Test? Gee, it's awfully quiet out there. Who expressed interest in an interop test? Speaking for the Xerox Channels Group, we do not have anything ready for an interop test in the next couple of months. Thanks, Angelo -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Wednesday, August 12, 1998 3:51 PM To: jmp@pwg.org Subject: JMP> Anyone for an Interoperability Test? There has been some interest in a Job Monitoring MIB interoperability test. Please respond if you have an interest and when will you be ready to test. Ron Bergman Dataproducts Corp. From don at lexmark.com Mon Sep 14 15:26:47 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Mailing Lists Message-ID: <199809141927.AA13984@interlock2.lexmark.com> The mailing lists are back up and running. Just to test everything out, I have sent this mail to ALL the mailing lists. If you get this mail on one list and not on another you think you should be on then I suggest you resubscribe by sending e-mail to: majordomo@pwg.org with the body of the note containing subscribe when is the name of the list you wish to subscribe to. You can include multiple subscriptions in the same note. Thanks for your patience during this transfer. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jfung at cp10.es.xerox.com Wed Sep 16 12:37:21 1998 From: jfung at cp10.es.xerox.com (Joseph Z. Fung) Date: Wed May 6 13:59:58 2009 Subject: JMP> Job Submission Protocol Mapping Implementation In-Reply-To: Message-ID: <3.0.1.32.19980916093721.0131ca28@goldie> Ron, As the author of the "Job Submission Protocol Mapping" specification, currently at version 10, could you share any known implementations to-date that are based on this recommendation? I am more interested in the mapping for submission protocols of lpr/lpd, PJL, and PostScript. Thank you very much in advance. //Joe Fung Xerox Corp. From rbergma at dpc.com Thu Sep 17 16:19:47 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> MIBs Meeting Schedule Message-ID: I propose that the evening MIBs meetings be either Wednesday or Thursday evening, rather than Tuesday. Most of the people attending this meeting do not attend the P1394 meetings. In many cases such as the Savannah meeting, it is difficult to arrive early enough to be at the start of the meeting. (I will be late to the UPD meeting which replaces the MIBs meeting in Savannah.) Rather than start the meeting later than 7:00, Wednesday would be much more convenient. Anyone object to Wednesday evening in Tucson? Comments? Ron Bergman Dataproducts Corp. From Stuart.Rowley at kyocera.com Thu Sep 17 17:48:49 1998 From: Stuart.Rowley at kyocera.com (Stuart Rowley) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: PWG> MIBs Meeting Schedule Message-ID: <00063E81.@kyocera.com> Ron, Yes, I'm in favor of MIBs on Wednesday nights. For Savannah I will likely miss the entire UPD meeting because my flight arrives at 6:55 PM although I leave SFO at 6:15 AM! Stuart Rowley Kyocera Technology Development ______________________________ Reply Separator _________________________________ Subject: PWG> MIBs Meeting Schedule Author: INTERNET:rbergma@dpc.com at CSERVE Date: 9/17/98 4:37 PM I propose that the evening MIBs meetings be either Wednesday or Thursday evening, rather than Tuesday. Most of the people attending this meeting do not attend the P1394 meetings. In many cases such as the Savannah meeting, it is difficult to arrive early enough to be at the start of the meeting. (I will be late to the UPD meeting which replaces the MIBs meeting in Savannah.) Rather than start the meeting later than 7:00, Wednesday would be much more convenient. Anyone object to Wednesday evening in Tucson? Comments? Ron Bergman Dataproducts Corp. From don at lexmark.com Fri Sep 18 10:09:36 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> MIBs Meeting Schedule Message-ID: <199809181410.AA15487@interlock2.lexmark.com> The reason we set this up for Tuesday was as Harry suggested -- it would be better to do this on an evening when you were fresh, i.e. not after an IPP meeting. Since most of the attendees do not attend 1394 meetings, most would be "fresh" having it on another day is alright me me, just make sure the meeting coordinator of Tucson (Alan Berkema) knows to ask for the room on Wednesday or Thursday evening rather than Tuesday. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Ron Bergman on 09/17/98 04:19:47 PM To: pwg%@pwg.org@interlock.lexmark.com, fin%@pwg.org@interlock.lexmark.com, jmp%@pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) bcc: Don Wright/Lex/Lexmark Subject: PWG> MIBs Meeting Schedule I propose that the evening MIBs meetings be either Wednesday or Thursday evening, rather than Tuesday. Most of the people attending this meeting do not attend the P1394 meetings. In many cases such as the Savannah meeting, it is difficult to arrive early enough to be at the start of the meeting. (I will be late to the UPD meeting which replaces the MIBs meeting in Savannah.) Rather than start the meeting later than 7:00, Wednesday would be much more convenient. Anyone object to Wednesday evening in Tucson? Comments? Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Sun Sep 20 17:12:10 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 13:59:58 2009 Subject: FIN> JMP> PMP> MIBs Meeting Schedule In-Reply-To: Message-ID: <3.0.5.32.19980920141210.00bcc330@garfield> I agree with Ron. Lets move the MIB meeting from Tuesday evening to Wednesday evening for Tucson (and future meetings). Tom At 13:19 09/17/98 PDT, Ron Bergman wrote: >I propose that the evening MIBs meetings be either Wednesday or Thursday >evening, rather than Tuesday. Most of the people attending this meeting >do not attend the P1394 meetings. In many cases such as the Savannah >meeting, it is difficult to arrive early enough to be at the start of the >meeting. (I will be late to the UPD meeting which replaces the MIBs >meeting in Savannah.) > >Rather than start the meeting later than 7:00, Wednesday would be much >more convenient. Anyone object to Wednesday evening in Tucson? > >Comments? > > > Ron Bergman > Dataproducts Corp. > > > > From rbergma at dpc.com Mon Sep 21 16:05:49 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: job mib feedback (fwd) Message-ID: As you can see there has been some activity directed towards the Job MIB since the last meeting. I received the following today from Bert Wijnen, who is helping to move the MIB to RFC status. I would like to discuss the following comments in the Savannah meeting on Friday. We need to either revise the document or justify our position. It is our best interests to revise the documents to conform as long as the change does not functionally change the MIB. Any comments or discussion prior to the meeting would be helpful. Ron Bergman Dataproducts Corp. ---------- Forwarded message ---------- Date: Mon, 21 Sep 98 20:25:11 DST From: Bert Wijnen To: rbergma@unspecified-domain, lpyoung@lexmark.com, chrisw@iwl.com Cc: moore@cs.utk.edu, hastings@cp10.es.xerox.com, harryl@us.ibm.com Subject: JMP> Re: job mib feedback (fwd) Ref: Your note of Mon, 21 Sep 1998 07:35:32 -0700 (Pacific Da Subject: Re: JMP> Re: job mib feedback (fwd) OK, if you are going to do another revision, then pls consider these comments. Up to you how much you pick up. >From Perkins: - misuse of the REFERENCE clause for objects to indicate implementation requirements, and - defining objects with read-only maximum access when it appears that at least read-write access is appropriate. There might be (and probably are) more technical problems, but my review time was limited. >From Keith McCloghrie 1. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. 2. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. 3. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. Bert From rbergma at dpc.com Mon Sep 28 16:18:33 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Job MIB Issues for Savannah PWG Meeting Message-ID: The following are issues relating to the Job MIB that should be discussed this Friday in Savannah. My recommended action is included with each item. A. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. From RFC 1902: "The REFERENCE clause, which need not be present contains a textual cross-reference to an object assignment defined in some other information module. This is useful when de-osifying a MIB module produced by some other organization." ACTION: Delete all REFERENCE clauses and move reference information into DESCRIPTION when appropriate. B. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. ACTION: Move all attribute enumeration definitions to a new section outside of the MIB portion. C. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. From RFC 2119: "These words are often capitalized." "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)" ACTION: Review the use of these words and remove or change to lower case any that are not absolutely necessary. D. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. ACTION: Respond to Keith McCloghrie explaining that this is not a standardized display format. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Sep 28 18:48:13 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Job MIB Issues for Savannah PWG Meeting Message-ID: <918C79AB552BD211A2BD00805F15CE8527F0D1@x-crt-es-ms1.cp10.es.xerox.com> I have some comments and questions. Perhaps some of these should be sent to the IESG commenters before the JMP meeting to get their feedback? Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Monday, September 28, 1998 13:19 To: jmp@pwg.org Cc: Tom Hastings Subject: JMP> Job MIB Issues for Savannah PWG Meeting The following are issues relating to the Job MIB that should be discussed this Friday in Savannah. My recommended action is included with each item. A. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. From RFC 1902: "The REFERENCE clause, which need not be present contains a textual cross-reference to an object assignment defined in some other information module. This is useful when de-osifying a MIB module produced by some other organization." ACTION: Delete all REFERENCE clauses and move reference information into DESCRIPTION when appropriate. TH> Ok. B. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. ACTION: Move all attribute enumeration definitions to a new section outside of the MIB portion. TH> The only reason that the definitions were ASN.1 comments, was because TH> an unnamed, but very popular and good, MIB compiler would not accept TH> a DESCRIPTION clause with that number of lines, so we had to make them TH> ASN.1 comments. TH> The question that I have is, if we move all attribute definitions TH> out of the MIB portion altogether, will we make the MIB module TH> almost useless when "the MIB, i.e., section 4, is required to be TH> extracted and used stand-alone" as described in point 1 above?. C. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. From RFC 2119: "These words are often capitalized." "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)" ACTION: Review the use of these words and remove or change to lower case any that are not absolutely necessary. TH> We should change any that are not required for interoperability. TH> However, I think that most of them are required for interoperability. D. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. ACTION: Respond to Keith McCloghrie explaining that this is not a standardized display format. TH> I agree. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Sep 28 18:50:46 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: job mib feedback (fwd) Message-ID: <918C79AB552BD211A2BD00805F15CE8527F0D4@x-crt-es-ms1.cp10.es.xerox.com> We may want to reply to David Perkins that we don't think that any of the object should be MAX ACCESS of READ-WRITE. This is only a Monitoring MIB. Should we? Thanks, Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Monday, September 21, 1998 13:06 To: jmp@pwg.org Subject: JMP> Re: job mib feedback (fwd) As you can see there has been some activity directed towards the Job MIB since the last meeting. I received the following today from Bert Wijnen, who is helping to move the MIB to RFC status. I would like to discuss the following comments in the Savannah meeting on Friday. We need to either revise the document or justify our position. It is our best interests to revise the documents to conform as long as the change does not functionally change the MIB. Any comments or discussion prior to the meeting would be helpful. Ron Bergman Dataproducts Corp. ---------- Forwarded message ---------- Date: Mon, 21 Sep 98 20:25:11 DST From: Bert Wijnen To: rbergma@unspecified-domain, lpyoung@lexmark.com, chrisw@iwl.com Cc: moore@cs.utk.edu, hastings@cp10.es.xerox.com, harryl@us.ibm.com Subject: JMP> Re: job mib feedback (fwd) Ref: Your note of Mon, 21 Sep 1998 07:35:32 -0700 (Pacific Da Subject: Re: JMP> Re: job mib feedback (fwd) OK, if you are going to do another revision, then pls consider these comments. Up to you how much you pick up. >From Perkins: - misuse of the REFERENCE clause for objects to indicate implementation requirements, and - defining objects with read-only maximum access when it appears that at least read-write access is appropriate. There might be (and probably are) more technical problems, but my review time was limited. >From Keith McCloghrie 1. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. 2. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. 3. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. Bert From hastings at cp10.es.xerox.com Tue Oct 6 20:24:11 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> I've posted Job MIB V1.2 with Savannah agreements Message-ID: <918C79AB552BD211A2BD00805F15CE8527F7C4@x-crt-es-ms1.cp10.es.xerox.com> This has the two new attributes agreed to last April: mediumSizeConsumed and mediumTypeConsumed and the IESG comments incorporated. The .txt file compiles. The files are at: ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.pdf I've not sent it as an I-D yet. Lets see if you have any comments. I'll also send out the mirror table ASN.1 separately for discussion in a day or two. Tom Hastings (310) 333-6413 From don at lexmark.com Wed Oct 7 15:37:22 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> I've posted Job MIB V1.2 with Savannah agreements Message-ID: <199810071937.AA18363@interlock2.lexmark.com> .... and the real URL has pwg between pub and jmp..... Don "Hastings, Tom N" on 10/06/98 08:24:11 PM To: jmp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) bcc: Don Wright/Lex/Lexmark Subject: JMP> I've posted Job MIB V1.2 with Savannah agreements This has the two new attributes agreed to last April: mediumSizeConsumed and mediumTypeConsumed and the IESG comments incorporated. The .txt file compiles. The files are at: ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.pdf I've not sent it as an I-D yet. Lets see if you have any comments. I'll also send out the mirror table ASN.1 separately for discussion in a day or two. Tom Hastings (310) 333-6413 From rbergma at dpc.com Thu Oct 8 16:46:06 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Review of Job Monitoring MIB of October 2, 1998 Message-ID: Tom, Your proposed changes look very good! I did notice that there are four other TCs that reflect the same situation as with JmAttributeTypeTC. They are: JmFinishingTypeTC JmMediumTypeTC JmJobSubmissionTypeTC JmJobStateTC In the case of the first two, the definitions could be added as comments with the enums. For the second two, the specs should also be moved out of the MIB and into the text I will submit a proposal for these changes unless the other JMP participants feel strongly that a change here is not required. Also the bit-mapped TCs are structured very different than what is in the current Printer MIB and the HR MIB. I suggest everyone look at this and indicate if we should revise. JmJobServiceTypesTC JmJobStateReasonsTC JmJobStateReasons2TC JmJobStateReasons3TC JmJobStateReasons4TC I see that you also changed this to v1.2 ( was v1 ). The editorial changes should not affect the revision status, nor should the addition of the 2 new enums. So I prefer that the MIB remain at v1. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Oct 12 11:51:10 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <918C79AB552BD211A2BD00805F15CE853A2A3B@x-crt-es-ms1.cp10.es.xerox.com> >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Thursday, October 08, 1998 13:46 >To: Tom Hastings; Harry Lewis >Cc: jmp@pwg.org >Subject: Review of Job Monitoring MIB of October 2, 1998 > > >Tom, > >Your proposed changes look very good! > >I did notice that there are four other TCs that reflect the >same situation >as with JmAttributeTypeTC. They are: > > JmFinishingTypeTC > JmMediumTypeTC > JmJobSubmissionTypeTC > JmJobStateTC > >In the case of the first two, the definitions could be added >as comments >with the enums. For the second two, the specs should also be >moved out of >the MIB and into the text > >I will submit a proposal for these changes unless the other JMP >participants feel strongly that a change here is not required. I don't think we should bother. It wasn't commented on by the IESG. Moving the explanations out of the TC makes them a lot harder to use. The information is spread to two places. For attributes, because there are so many, it makes sense to move them out. I think that they really objected to having -- in the middle of a DESCRIPTION clause (which I removed in doing 1.2. >Also the bit-mapped TCs are structured very different than >what is in the >current Printer MIB and the HR MIB. I suggest everyone look >at this and >indicate if we should revise. > > JmJobServiceTypesTC > JmJobStateReasonsTC > JmJobStateReasons2TC > JmJobStateReasons3TC > JmJobStateReasons4TC Since the IESG folks didn't comment on them, I think they are fine having the bit assignments and the description of each bit as part of the DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness as hex in the description, then as the decimal equivalent. > >I see that you also changed this to v1.2 ( was v1 ). The editorial >changes should not affect the revision status, nor should the >addition of >the 2 new enums. So I prefer that the MIB remain at v1. Yikes! There would be a terrible confusion problem if we use the same version number for two different versions of the MIB. The minor version number changes shows that some attributes have been added and/ or clarifications. If we don't have a different version number, how can you tell which MIB you have? (Of course, if the TCs were a separate file, then the MIB part could have kept the same version number. But suppose there had been some clarification text added to even the MIB part, then you wind up incrementing the MIB module version number anyway. > > > Ron Bergman > Dataproducts Corp. > > From rbergma at dpc.com Tue Oct 13 10:48:50 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 In-Reply-To: <918C79AB552BD211A2BD00805F15CE853A2A3B@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, Since there have been no comments from others regarding the changes to the TCs, I assume no one else cares. I have this feeling that this will be another issue with the IETF, so I believe it is best if we beat them to the draw. So, unless others support my position, keep it as is. Concerning the version number change, your reply indicates that new attributes and enums cannot be added unless the version number is changed. This is clearly not true. So what other than the editorial changes and the addition of the two attributes makes this version 1.2? Ron On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Thursday, October 08, 1998 13:46 > >To: Tom Hastings; Harry Lewis > >Cc: jmp@pwg.org > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > >Tom, > > > >Your proposed changes look very good! > > > >I did notice that there are four other TCs that reflect the > >same situation > >as with JmAttributeTypeTC. They are: > > > > JmFinishingTypeTC > > JmMediumTypeTC > > JmJobSubmissionTypeTC > > JmJobStateTC > > > >In the case of the first two, the definitions could be added > >as comments > >with the enums. For the second two, the specs should also be > >moved out of > >the MIB and into the text > > > >I will submit a proposal for these changes unless the other JMP > >participants feel strongly that a change here is not required. > > I don't think we should bother. It wasn't commented on by the IESG. Moving > the explanations out of the TC makes them a lot harder to use. The > information is spread to two places. For attributes, because there are so > many, it makes sense to move them out. > > I think that they really objected to having -- in the middle of a > DESCRIPTION clause (which I removed in doing 1.2. > > >Also the bit-mapped TCs are structured very different than > >what is in the > >current Printer MIB and the HR MIB. I suggest everyone look > >at this and > >indicate if we should revise. > > > > JmJobServiceTypesTC > > JmJobStateReasonsTC > > JmJobStateReasons2TC > > JmJobStateReasons3TC > > JmJobStateReasons4TC > > Since the IESG folks didn't comment on them, I think they are fine having > the bit assignments and the description of each bit as part of the > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > as hex in the description, then as the decimal equivalent. > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > >changes should not affect the revision status, nor should the > >addition of > >the 2 new enums. So I prefer that the MIB remain at v1. > > Yikes! There would be a terrible confusion problem if we use the same > version number for two different versions of the MIB. The minor version > number changes shows that some attributes have been added and/ or > clarifications. > > If we don't have a different version number, how can you tell which MIB you > have? (Of course, if the TCs were a separate file, then the MIB part could > have kept the same version number. But suppose there had been some > clarification text added to even the MIB part, then you wind up incrementing > the MIB module version number anyway. > > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > From harryl at us.ibm.com Tue Oct 13 12:31:16 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 13:59:58 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <5030100027086306000002L062*@MHS> You were just recommending moving TC's to a consolidated place in the document... right? I didn't see any problem with doing that. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 10/13/98 09:07:33 AM Please respond to jmp-owner@pwg.org To: hastings@cp10.es.xerox.com cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Tom, Since there have been no comments from others regarding the changes to the TCs, I assume no one else cares. I have this feeling that this will be another issue with the IETF, so I believe it is best if we beat them to the draw. So, unless others support my position, keep it as is. Concerning the version number change, your reply indicates that new attributes and enums cannot be added unless the version number is changed. This is clearly not true. So what other than the editorial changes and the addition of the two attributes makes this version 1.2? Ron On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Thursday, October 08, 1998 13:46 > >To: Tom Hastings; Harry Lewis > >Cc: jmp@pwg.org > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > >Tom, > > > >Your proposed changes look very good! > > > >I did notice that there are four other TCs that reflect the > >same situation > >as with JmAttributeTypeTC. They are: > > > > JmFinishingTypeTC > > JmMediumTypeTC > > JmJobSubmissionTypeTC > > JmJobStateTC > > > >In the case of the first two, the definitions could be added > >as comments > >with the enums. For the second two, the specs should also be > >moved out of > >the MIB and into the text > > > >I will submit a proposal for these changes unless the other JMP > >participants feel strongly that a change here is not required. > > I don't think we should bother. It wasn't commented on by the IESG. Moving > the explanations out of the TC makes them a lot harder to use. The > information is spread to two places. For attributes, because there are so > many, it makes sense to move them out. > > I think that they really objected to having -- in the middle of a > DESCRIPTION clause (which I removed in doing 1.2. > > >Also the bit-mapped TCs are structured very different than > >what is in the > >current Printer MIB and the HR MIB. I suggest everyone look > >at this and > >indicate if we should revise. > > > > JmJobServiceTypesTC > > JmJobStateReasonsTC > > JmJobStateReasons2TC > > JmJobStateReasons3TC > > JmJobStateReasons4TC > > Since the IESG folks didn't comment on them, I think they are fine having > the bit assignments and the description of each bit as part of the > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > as hex in the description, then as the decimal equivalent. > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > >changes should not affect the revision status, nor should the > >addition of > >the 2 new enums. So I prefer that the MIB remain at v1. > > Yikes! There would be a terrible confusion problem if we use the same > version number for two different versions of the MIB. The minor version > number changes shows that some attributes have been added and/ or > clarifications. > > If we don't have a different version number, how can you tell which MIB you > have? (Of course, if the TCs were a separate file, then the MIB part could > have kept the same version number. But suppose there had been some > clarification text added to even the MIB part, then you wind up incrementing > the MIB module version number anyway. > > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > From rbergma at dpc.com Tue Oct 13 16:47:11 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 In-Reply-To: <5030100027086306000002L062*@MHS> Message-ID: Harry, What I see in the MIB is four other TCs that, like JmAttributeTypeTC, contain very long, detailed specifications of each enumeration in the TC definition. The specification details should be removed from the MIB section. I don't want this to come back from the ADs as aonther fix. If it easy to fix, and I don't see why not, I prefer to do it now and be done with it. Does this make the MIB harder to use? Maybe, maybe not. With all the cross references we have, I don'e see how it could be that much more difficult. Any opinions? Ron Bergman Dataproducts Corp. On Tue, 13 Oct 1998, Harry Lewis wrote: > You were just recommending moving TC's to a consolidated place in the > document... right? I didn't see any problem with doing that. > > Harry Lewis - IBM Printing Systems > > > > jmp-owner@pwg.org on 10/13/98 09:07:33 AM > Please respond to jmp-owner@pwg.org > To: hastings@cp10.es.xerox.com > cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com > Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > > Tom, > > Since there have been no comments from others regarding the changes to the > TCs, I assume no one else cares. I have this feeling that this will be > another issue with the IETF, so I believe it is best if we beat them to > the draw. So, unless others support my position, keep it as is. > > Concerning the version number change, your reply indicates that new > attributes and enums cannot be added unless the version number is changed. > This is clearly not true. So what other than the editorial changes and > the addition of the two attributes makes this version 1.2? > > > Ron > > > On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > > > > > >-----Original Message----- > > >From: Ron Bergman [mailto:rbergma@dpc.com] > > >Sent: Thursday, October 08, 1998 13:46 > > >To: Tom Hastings; Harry Lewis > > >Cc: jmp@pwg.org > > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > > > > >Tom, > > > > > >Your proposed changes look very good! > > > > > >I did notice that there are four other TCs that reflect the > > >same situation > > >as with JmAttributeTypeTC. They are: > > > > > > JmFinishingTypeTC > > > JmMediumTypeTC > > > JmJobSubmissionTypeTC > > > JmJobStateTC > > > > > >In the case of the first two, the definitions could be added > > >as comments > > >with the enums. For the second two, the specs should also be > > >moved out of > > >the MIB and into the text > > > > > >I will submit a proposal for these changes unless the other JMP > > >participants feel strongly that a change here is not required. > > > > I don't think we should bother. It wasn't commented on by the IESG. Moving > > the explanations out of the TC makes them a lot harder to use. The > > information is spread to two places. For attributes, because there are so > > many, it makes sense to move them out. > > > > I think that they really objected to having -- in the middle of a > > DESCRIPTION clause (which I removed in doing 1.2. > > > > >Also the bit-mapped TCs are structured very different than > > >what is in the > > >current Printer MIB and the HR MIB. I suggest everyone look > > >at this and > > >indicate if we should revise. > > > > > > JmJobServiceTypesTC > > > JmJobStateReasonsTC > > > JmJobStateReasons2TC > > > JmJobStateReasons3TC > > > JmJobStateReasons4TC > > > > Since the IESG folks didn't comment on them, I think they are fine having > > the bit assignments and the description of each bit as part of the > > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > > as hex in the description, then as the decimal equivalent. > > > > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > > >changes should not affect the revision status, nor should the > > >addition of > > >the 2 new enums. So I prefer that the MIB remain at v1. > > > > Yikes! There would be a terrible confusion problem if we use the same > > version number for two different versions of the MIB. The minor version > > number changes shows that some attributes have been added and/ or > > clarifications. > > > > If we don't have a different version number, how can you tell which MIB you > > have? (Of course, if the TCs were a separate file, then the MIB part could > > have kept the same version number. But suppose there had been some > > clarification text added to even the MIB part, then you wind up incrementing > > the MIB module version number anyway. > > > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > > > > > > > From harryl at us.ibm.com Tue Oct 13 17:47:11 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 13:59:58 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <5030100027103065000002L052*@MHS> I agree with Ron. My main concern is that we not disturb the actual operation of the MIB... this appears to be strictly a documentation issue. Since the IETF mentioned one such example, if we have found 4 similar I think it best to respond. Harry Lewis - IBM Printing Systems rbergma@dpc.com on 10/13/98 03:02:46 PM Please respond to rbergma@dpc.com To: Harry Lewis/Boulder/IBM@ibmus cc: hastings@cp10.es.xerox.com, jmp@pwg.org Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Harry, What I see in the MIB is four other TCs that, like JmAttributeTypeTC, contain very long, detailed specifications of each enumeration in the TC definition. The specification details should be removed from the MIB section. I don't want this to come back from the ADs as aonther fix. If it easy to fix, and I don't see why not, I prefer to do it now and be done with it. Does this make the MIB harder to use? Maybe, maybe not. With all the cross references we have, I don'e see how it could be that much more difficult. Any opinions? Ron Bergman Dataproducts Corp. On Tue, 13 Oct 1998, Harry Lewis wrote: > You were just recommending moving TC's to a consolidated place in the > document... right? I didn't see any problem with doing that. > > Harry Lewis - IBM Printing Systems > > > > jmp-owner@pwg.org on 10/13/98 09:07:33 AM > Please respond to jmp-owner@pwg.org > To: hastings@cp10.es.xerox.com > cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com > Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > > Tom, > > Since there have been no comments from others regarding the changes to the > TCs, I assume no one else cares. I have this feeling that this will be > another issue with the IETF, so I believe it is best if we beat them to > the draw. So, unless others support my position, keep it as is. > > Concerning the version number change, your reply indicates that new > attributes and enums cannot be added unless the version number is changed. > This is clearly not true. So what other than the editorial changes and > the addition of the two attributes makes this version 1.2? > > > Ron > > > On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > > > > > >-----Original Message----- > > >From: Ron Bergman [mailto:rbergma@dpc.com] > > >Sent: Thursday, October 08, 1998 13:46 > > >To: Tom Hastings; Harry Lewis > > >Cc: jmp@pwg.org > > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > > > > >Tom, > > > > > >Your proposed changes look very good! > > > > > >I did notice that there are four other TCs that reflect the > > >same situation > > >as with JmAttributeTypeTC. They are: > > > > > > JmFinishingTypeTC > > > JmMediumTypeTC > > > JmJobSubmissionTypeTC > > > JmJobStateTC > > > > > >In the case of the first two, the definitions could be added > > >as comments > > >with the enums. For the second two, the specs should also be > > >moved out of > > >the MIB and into the text > > > > > >I will submit a proposal for these changes unless the other JMP > > >participants feel strongly that a change here is not required. > > > > I don't think we should bother. It wasn't commented on by the IESG. Moving > > the explanations out of the TC makes them a lot harder to use. The > > information is spread to two places. For attributes, because there are so > > many, it makes sense to move them out. > > > > I think that they really objected to having -- in the middle of a > > DESCRIPTION clause (which I removed in doing 1.2. > > > > >Also the bit-mapped TCs are structured very different than > > >what is in the > > >current Printer MIB and the HR MIB. I suggest everyone look > > >at this and > > >indicate if we should revise. > > > > > > JmJobServiceTypesTC > > > JmJobStateReasonsTC > > > JmJobStateReasons2TC > > > JmJobStateReasons3TC > > > JmJobStateReasons4TC > > > > Since the IESG folks didn't comment on them, I think they are fine having > > the bit assignments and the description of each bit as part of the > > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > > as hex in the description, then as the decimal equivalent. > > > > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > > >changes should not affect the revision status, nor should the > > >addition of > > >the 2 new enums. So I prefer that the MIB remain at v1. > > > > Yikes! There would be a terrible confusion problem if we use the same > > version number for two different versions of the MIB. The minor version > > number changes shows that some attributes have been added and/ or > > clarifications. > > > > If we don't have a different version number, how can you tell which MIB you > > have? (Of course, if the TCs were a separate file, then the MIB part could > > have kept the same version number. But suppose there had been some > > clarification text added to even the MIB part, then you wind up incrementing > > the MIB module version number anyway. > > > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > > > > > > > From rbergma at dpc.com Tue Oct 13 21:21:35 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> MIBs Meeting Minutes from Savannah Message-ID: The meeting minutes are posted as follows. These are from Harry Lewis' and my notes. I created one set of minutes for the entire day and posted to both the JMP and FIN directories. ftp://ftp.pwg.org/pub/pug/jmp/minutes/jmp-1098.doc (.txt) ftp://ftp.pwg.org/pub/pug/fin/minutes/fin-1098.doc (.txt) The text version is attached: Ron Bergman Dataproducts Corp. -------------- next part -------------- PWG MIBs MEETING MINUTES Savannah, Georgia October 2, 1998 Job MIB Although the Job MIB has been a completed PWG standard for several months, there have been some recent comments from the IETF in response to our efforts to have them published as RFC standards. 1. The MIB is entirely R/O. (This is by design). ACTION: Respond to David Perkins explaining that this is only a monitoring MIB. For security reasons, the Working Group agreed that the MIB would not contain any read- write objects. 2. We have inadvertently misused the REFERENCE clause. ACTION: Delete all REFERENCE clauses and move reference information into the DESCRIPTION clause when appropriate. 3. We need to move the definition of enumerated labels to a new section outside of the MIB portion. 4. We MIGHT have used too many SHOULDs and SHALLs (surprised? ;-). ACTION: Review the use of these words and remove or change to lower case any that are not absolutely necessary. 5. JobProcessAfterDateAndTime - there was a comment about improper or nonstandard use, but we do not understand the comment. We need to clarify with the reviewer. ACTION: Respond to Keith McCloghrie explaining that this is not a standardized display format. Tom Hastings comments: 1. A new draft was presented with changes in response to items 2, 3, and 4. 2. Two new attributes added - mediumTypeConsumed and SizeConsumed. Both attributes were previously approved as additions to the MIB. 3. Tom will remove attributes from the table of contents just for brevity. New Issue: Tom Hastings presented a problem discovered by Xerox in using the GetBulk operation with the Attribute table. The present table configuration allows GetBulk to work to obtain all the attributes for a given job or a number of jobs. Tom has proposed a mirror table that inverts the order of the indices so that a GetBulk can obtain an attribute for all jobs. This addition would result in enhanced performance on the client side. Tom will draft the required text and post to the mail list. Today - the Attribute Table is indexed by: - Job index - Attribute type index - Attribute instance The proposed Mirror Table would be indexed by: - Attribute instance - Attribute type index - Job index Job MIB interoperability testing may be possibly within appx. 6 months. Finisher MIB: MIB Changes: 1. Moved the MODULE-IDENTITY to { experimental 64 } Accepted 2. Added the following enums to FinStitchingTypeTC: Accepted stapleDualTop(10), stapleDualBottom(11), stapleDualLeft(12), stapleDualRight(13) 3. Added a new attribute and textual convention: Accepted but change to a type 2 enum and change bottomUp(5) to bottomUp(4). stitchingDirection(31), StitchingDirTypeTC INTEGER: Defines the orientation of the stitching process. StitchingDirTypeTC ::= TEXTUAL-CONVENTION -- This is a type 1 enumeration. STATUS current DESCRIPTION "Defines the direction, relative to the top sheet in the output subunit, that the stitching operation was performed. For a topDown(3) process, the staple will be clinched on the bottom of the stack. This parameter can be used to determine what order the pages of a booklet are to be printed such that the staple clinch will be on the inside of the resulting booklet." SYNTAX INTEGER { unknown(2), topDown(3), bottomUp(5) } 4. Removed the following note from section 6.1: Rejected, new enum is changed to type 2. "There are no type 1 enums in the current draft." 5. As a result of the discussions concerning the Job MIB it was also discussed and agreed to move the specification of the attributes used by FinAttributeTypeTC out from the MIB body and into the text. New Issues from Sharp: 1. Several index objects allow a value of 0. The minimum value should be 1. The following index objects will be changed to correct this problem. finDeviceIndex finSupplyIndex finSupplyMediaInputIndex finDeviceAttributeInstanceIndex 2. There is no enumeration in prtMarkerSupplyUnitTC that is appropriate to staples. It was agreed that an enum, such as "units" or "each" should be added to the TC in the Printer MIB. Common Finisher Interface Discussion: Kevin Palmer (Duplo) had agreed to generate a proposal for the Finisher Device Command Set and the Finisher features, functions, characteristics, and status. Kevin was unable to attend the meeting, but he did submit a list of items that pertain to the above subjects. After a brief review, the group decided that there was not sufficient information to generate further discussion. No additional work on this topic will occur until Kevin's complete proposal is received. Harry Lewis - IBM Printing Systems Ron Bergman - Dataproducts Corp. From harryl at us.ibm.com Wed Oct 14 10:25:50 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 13:59:58 2009 Subject: JMP> Minutes PDF Message-ID: <5030100027135838000002L082*@MHS> Ron wrote >The meeting minutes are posted as follows. These are from Harry Lewis' >and my notes. I created one set of minutes for the entire day and posted >to both the JMP and FIN directories. > > ftp://ftp.pwg.org/pub/pug/jmp/minutes/jmp-1098.doc (.txt) > ftp://ftp.pwg.org/pub/pug/fin/minutes/fin-1098.doc (.txt) I posted PDF of same. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed Oct 21 11:54:50 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <918C79AB552BD211A2BD00805F15CE853A3486@x-crt-es-ms1.cp10.es.xerox.com> Ok. I'll make the edits. Tom >-----Original Message----- >From: Harry Lewis [mailto:harryl@us.ibm.com] >Sent: Tuesday, October 13, 1998 14:47 >To: rbergma@dpc.com >Cc: jmp@pwg.org; hastings@cp10.es.xerox.com >Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > >I agree with Ron. My main concern is that we not disturb the >actual operation >of the MIB... this appears to be strictly a documentation >issue. Since the IETF >mentioned one such example, if we have found 4 similar I think >it best to >respond. > >Harry Lewis - IBM Printing Systems > > > >rbergma@dpc.com on 10/13/98 03:02:46 PM >Please respond to rbergma@dpc.com >To: Harry Lewis/Boulder/IBM@ibmus >cc: hastings@cp10.es.xerox.com, jmp@pwg.org >Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > >Harry, > >What I see in the MIB is four other TCs that, like JmAttributeTypeTC, >contain very long, detailed specifications of each enumeration >in the TC >definition. The specification details should be removed from the MIB >section. I don't want this to come back from the ADs as aonther fix. >If it easy to fix, and I don't see why not, I prefer to do it >now and be >done with it. > >Does this make the MIB harder to use? Maybe, maybe not. With all the >cross references we have, I don'e see how it could be that much more >difficult. > >Any opinions? > > Ron Bergman > Dataproducts Corp. > > >On Tue, 13 Oct 1998, Harry Lewis wrote: > >> You were just recommending moving TC's to a consolidated place in the >> document... right? I didn't see any problem with doing that. >> >> Harry Lewis - IBM Printing Systems >> >> >> >> jmp-owner@pwg.org on 10/13/98 09:07:33 AM >> Please respond to jmp-owner@pwg.org >> To: hastings@cp10.es.xerox.com >> cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com >> Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 >> >> >> Tom, >> >> Since there have been no comments from others regarding the >changes to the >> TCs, I assume no one else cares. I have this feeling that >this will be >> another issue with the IETF, so I believe it is best if we >beat them to >> the draw. So, unless others support my position, keep it as is. >> >> Concerning the version number change, your reply indicates that new >> attributes and enums cannot be added unless the version >number is changed. >> This is clearly not true. So what other than the editorial >changes and >> the addition of the two attributes makes this version 1.2? >> >> >> Ron >> >> >> On Mon, 12 Oct 1998, Hastings, Tom N wrote: >> >> > >> > >> > >-----Original Message----- >> > >From: Ron Bergman [mailto:rbergma@dpc.com] >> > >Sent: Thursday, October 08, 1998 13:46 >> > >To: Tom Hastings; Harry Lewis >> > >Cc: jmp@pwg.org >> > >Subject: Review of Job Monitoring MIB of October 2, 1998 >> > > >> > > >> > >Tom, >> > > >> > >Your proposed changes look very good! >> > > >> > >I did notice that there are four other TCs that reflect the >> > >same situation >> > >as with JmAttributeTypeTC. They are: >> > > >> > > JmFinishingTypeTC >> > > JmMediumTypeTC >> > > JmJobSubmissionTypeTC >> > > JmJobStateTC >> > > >> > >In the case of the first two, the definitions could be added >> > >as comments >> > >with the enums. For the second two, the specs should also be >> > >moved out of >> > >the MIB and into the text >> > > >> > >I will submit a proposal for these changes unless the other JMP >> > >participants feel strongly that a change here is not required. >> > >> > I don't think we should bother. It wasn't commented on by >the IESG. Moving >> > the explanations out of the TC makes them a lot harder to use. The >> > information is spread to two places. For attributes, >because there are so >> > many, it makes sense to move them out. >> > >> > I think that they really objected to having -- in the middle of a >> > DESCRIPTION clause (which I removed in doing 1.2. >> > >> > >Also the bit-mapped TCs are structured very different than >> > >what is in the >> > >current Printer MIB and the HR MIB. I suggest everyone look >> > >at this and >> > >indicate if we should revise. >> > > >> > > JmJobServiceTypesTC >> > > JmJobStateReasonsTC >> > > JmJobStateReasons2TC >> > > JmJobStateReasons3TC >> > > JmJobStateReasons4TC >> > >> > Since the IESG folks didn't comment on them, I think they >are fine having >> > the bit assignments and the description of each bit as part of the >> > DESCRIPTION clause. Also I think it is a lot clearer to >show the bit-ness >> > as hex in the description, then as the decimal equivalent. >> > >> > > >> > >I see that you also changed this to v1.2 ( was v1 ). The >editorial >> > >changes should not affect the revision status, nor should the >> > >addition of >> > >the 2 new enums. So I prefer that the MIB remain at v1. >> > >> > Yikes! There would be a terrible confusion problem if we >use the same >> > version number for two different versions of the MIB. The >minor version >> > number changes shows that some attributes have been added and/ or >> > clarifications. >> > >> > If we don't have a different version number, how can you >tell which MIB you >> > have? (Of course, if the TCs were a separate file, then >the MIB part could >> > have kept the same version number. But suppose there had been some >> > clarification text added to even the MIB part, then you >wind up incrementing >> > the MIB module version number anyway. >> > >> > > >> > > >> > > Ron Bergman >> > > Dataproducts Corp. >> > > >> > > >> > >> >> >> >> >> > > > > > From hastings at cp10.es.xerox.com Wed Oct 21 11:56:00 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute table Message-ID: <918C79AB552BD211A2BD00805F15CE853A3487@x-crt-es-ms1.cp10.es.xerox.com> This mail message contains the complete ASN.1 for the proposal for an OPTIONAL mirror table to be considered for addition to the PWG Job Monitoring MIB. It was agreed at the Savannah JMP meeting that I should forward such a proposal to the jmp mailing list. As also agreed at the Savannah JMP meeting, the implementers from Xerox (and others) will discuss on the jmp mailing list the benefits of this new table for improving the performance of applications that monitoring jobs. The IBM implementers (and others) will discuss whether there are other ways to improve the performance, base on their experience with implementation. NOTE: David Perkin's book on SNMP contains discussion of just such a mirror table in order to give different access methods to the same data. As agreed in Savannah, there are three possible outcomes of the jmp e-mail discussions: 1. The mirror table is not considered worth adding even as an OPTIONAL table, since there are other techniques for getting good performance that do not require any changes to the MIB. 2. The mirror table helps performance sufficiently for some applications, that it should be added as an OPTIONAL table (as proposed in this mail message). 3. The mirror table helps performance sufficiently for most applications, and is not a burden to implementation (since only the pointers, not the actual data occurs twice), that it should be made a MANDATORY table. Hopefully the discussions on the mailing list will be sufficiently conclusive that we can finalized on one of the above three courses of action at the upcoming JMP meeting, Tuesday morning, November 10. Discussion ---------------- The 'jmMirrorAttrTable' is a proposed addition to the PWG Job Mon MIB. It supports efficient access to selected job attributes (e.g., reading 'processingMessage' and 'jobStateReasons[2-4]' for all jobs in a job set) via SNMPv1 GetNext or SNMPv2 GetBulk. We have included updates for the MODULE-COMPLIANCE and OBJECT-GROUP macros too. - Ira McDonald SS&A Globalisation Consulting Architect, XCMI Editor 906-494-2434 (work) 906-494-2697 (home) - Tom Hastings PWG Job Monitoring MIB editor (310)333-6413 (work) ------------------------------------------------------------------------ -- The Mirror Attribute Group (OPTIONAL) -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. -- -- Implementation of the objects in this group is OPTIONAL. -- See Section 3.1 entitled 'Conformance Considerations'. -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. -- An agent which implements the jmMirrorAttrTable SHALL create a -- row in the jmMirrorAttrTable when each corresponding row is -- created in the jmAttributeTable. jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } jmMirrorAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmMirrorAttrTable is an OPTIONAL table which contains all of the same attributes for each job that are contained in the jmAttributeTable. Each entry in jmMirrorAttrTable corresponds one-to-one to an entry in jmAttributeTable. See the analogous jmAttributeTable for further details. The jmMirrorAttrTable supports efficient access to all of the attributes that an implementation supports, sorted by attribute type (traditional SNMP MIB access), rather than being sorted by job set and job index (modern object-oriented access) as in the analogous jmAttributeTable. An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." ::= { jmMirror 1 } jmMirrorAttrEntry OBJECT-TYPE SYNTAX JmMirrorAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attributes that represent information about each job and documents or resources required and/or consumed. Each entry in jmMirrorAttrTable corresponds one-to-one to an entry in jmAttributeTable. See the analogous jmAttributeEntry for further details. Each entry in jmMirrorAttrTable is a per-attribute entry with a primary index for each type of attribute (jmMirrorAttrTypeIndex) that a job can have and secondary indices which specify job set (jmJobSetIndex), job instance (jmJobIndex), and attribute instance (jmMirrorAttrInstanceIndex). An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, jmMirrorAttrInstanceIndex } ::= { jmMirrorAttrTable 1 } JmMirrorAttrEntry ::= SEQUENCE { jmMirrorAttrTypeIndex JmAttributeTypeTC, jmMirrorAttrInstanceIndex Integer32 (1..32767), jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) } jmMirrorAttrTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. See jmAttributeTypeIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 1 } jmMirrorAttrInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of attribute that this row entry represents. See jmAttributeInstanceIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 2 } jmMirrorAttrValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. See jmAttributeValueAsInteger in jmAttributeTable for complete description." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmMirrorAttrEntry 3 } jmMirrorAttrValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. See jmAttributeValueAsOctets in jmAttributeTable for complete description." DEFVAL { ''H } -- empty string ::= { jmMirrorAttrEntry 4 } ------------------------------------------------------------------------ [for placement in 'jmMIBCompliance' before the first OBJECT clause] GROUP jmMirrorAttrGroup DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable." ------------------------------------------------------------------------ [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] jmMirrorAttrGroup OBJECT-GROUP OBJECTS { jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } STATUS current DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable." ::= { jmMIBGroups 5 } ------------------------------------------------------------------------ Tom Hastings (310) 333-6413 From rbergma at dpc.com Mon Nov 2 12:05:19 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute table In-Reply-To: <918C79AB552BD211A2BD00805F15CE853A3487@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, I support your proposal to add the optional mirror attribute table to the Job MIB. However, I would like to suggest the following text in place of your proposed text. My changes eliminate much of the very repetitive text that was included in your original draft. Also, you state that section 3.3 contains a description of jmMirrorAttrTable, but you did not provide any changes to this section with this description. (My revised text still contains this reference.) Ron Bergman Dataproducts Corp. ------------------------------------------------------------------------ -- The Mirror Attribute Group (OPTIONAL) -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. -- -- Implementation of the objects in this group is OPTIONAL. -- See Section 3.1 entitled 'Conformance Considerations'. -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. -- -- The jmMirrorAttrTable provides efficient access to all of the -- attributes that an implementation supports, sorted by attribute -- type (traditional SNMP MIB access), rather than being sorted by -- job set and job index (modern object-oriented access) as in the -- analogous jmAttributeTable. jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } jmMirrorAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmMirrorAttrTable is an OPTIONAL table which provides identical attributes to the jmAttributeTable but with a different index structure. See jmAttributeTable for further details. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." ::= { jmMirror 1 } jmMirrorAttrEntry OBJECT-TYPE SYNTAX JmMirrorAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attributes that represent information about each job and documents or resources required and/or consumed. Each entry in jmMirrorAttrTable is a per-attribute entry with a primary index for each type of attribute (jmMirrorAttrTypeIndex) that a job can have and secondary indices which specify job set (jmJobSetIndex), job instance (jmJobIndex), and attribute instance (jmMirrorAttrInstanceIndex). An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, jmMirrorAttrInstanceIndex } ::= { jmMirrorAttrTable 1 } JmMirrorAttrEntry ::= SEQUENCE { jmMirrorAttrTypeIndex JmAttributeTypeTC, jmMirrorAttrInstanceIndex Integer32 (1..32767), jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) } jmMirrorAttrTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. See jmAttributeTypeIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 1 } jmMirrorAttrInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of attribute that this row entry represents. See jmAttributeInstanceIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 2 } jmMirrorAttrValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. See jmAttributeValueAsInteger in jmAttributeTable for complete description." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmMirrorAttrEntry 3 } jmMirrorAttrValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. See jmAttributeValueAsOctets in jmAttributeTable for complete description." DEFVAL { ''H } -- empty string ::= { jmMirrorAttrEntry 4 } ------------------------------------------------------------------------ [for placement in 'jmMIBCompliance' before the first OBJECT clause] GROUP jmMirrorAttrGroup DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ------------------------------------------------------------------------ [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] jmMirrorAttrGroup OBJECT-GROUP OBJECTS { jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } STATUS current DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ::= { jmMIBGroups 5 } ------------------------------------------------------------------------ From harryl at us.ibm.com Mon Nov 2 14:18:30 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribu Message-ID: <5030100027990620000002L002*@MHS> I agree with the addition of an OPTIONAL mirror attribute table and accept Ron's modifications. I'd like to propose one MINOR change, myself... Rather than -- The jmMirrorAttrTable provides efficient access to all of the -- attributes that an implementation supports, sorted by attribute -- type (traditional SNMP MIB access), rather than being sorted by -- job set and job index (modern object-oriented access) as in the -- analogous jmAttributeTable. I request deletion of the word "efficient" in the above. I think, when we developed the tables we have, we did so because we felt it was efficient. I think both methods are efficient based on different perspectives and, therefor, there is no need to embellish the paragraph. Harry Lewis - IBM Printing Systems harryl@us.ibm.com jmp-owner@pwg.org on 11/01/98 10:26:53 PM Please respond to jmp-owner@pwg.org To: hastings@cp10.es.xerox.com cc: jmp@pwg.org Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribu Tom, I support your proposal to add the optional mirror attribute table to the Job MIB. However, I would like to suggest the following text in place of your proposed text. My changes eliminate much of the very repetitive text that was included in your original draft. Also, you state that section 3.3 contains a description of jmMirrorAttrTable, but you did not provide any changes to this section with this description. (My revised text still contains this reference.) Ron Bergman Dataproducts Corp. ------------------------------------------------------------------------ -- The Mirror Attribute Group (OPTIONAL) -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. -- -- Implementation of the objects in this group is OPTIONAL. -- See Section 3.1 entitled 'Conformance Considerations'. -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. -- -- The jmMirrorAttrTable provides efficient access to all of the -- attributes that an implementation supports, sorted by attribute -- type (traditional SNMP MIB access), rather than being sorted by -- job set and job index (modern object-oriented access) as in the -- analogous jmAttributeTable. jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } jmMirrorAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmMirrorAttrTable is an OPTIONAL table which provides identical attributes to the jmAttributeTable but with a different index structure. See jmAttributeTable for further details. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." ::= { jmMirror 1 } jmMirrorAttrEntry OBJECT-TYPE SYNTAX JmMirrorAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attributes that represent information about each job and documents or resources required and/or consumed. Each entry in jmMirrorAttrTable is a per-attribute entry with a primary index for each type of attribute (jmMirrorAttrTypeIndex) that a job can have and secondary indices which specify job set (jmJobSetIndex), job instance (jmJobIndex), and attribute instance (jmMirrorAttrInstanceIndex). An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, jmMirrorAttrInstanceIndex } ::= { jmMirrorAttrTable 1 } JmMirrorAttrEntry ::= SEQUENCE { jmMirrorAttrTypeIndex JmAttributeTypeTC, jmMirrorAttrInstanceIndex Integer32 (1..32767), jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) } jmMirrorAttrTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. See jmAttributeTypeIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 1 } jmMirrorAttrInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of attribute that this row entry represents. See jmAttributeInstanceIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 2 } jmMirrorAttrValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. See jmAttributeValueAsInteger in jmAttributeTable for complete description." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmMirrorAttrEntry 3 } jmMirrorAttrValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. See jmAttributeValueAsOctets in jmAttributeTable for complete description." DEFVAL { ''H } -- empty string ::= { jmMirrorAttrEntry 4 } ------------------------------------------------------------------------ [for placement in 'jmMIBCompliance' before the first OBJECT clause] GROUP jmMirrorAttrGroup DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ------------------------------------------------------------------------ [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] jmMirrorAttrGroup OBJECT-GROUP OBJECTS { jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } STATUS current DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ::= { jmMIBGroups 5 } ------------------------------------------------------------------------ From rbergma at dpc.com Mon Nov 2 16:44:41 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribu In-Reply-To: <5030050023017534000002L542*@MHS> Message-ID: Harry, I agree! Good change! Ron On Mon, 2 Nov 1998, Harry Lewis wrote: > I agree with the addition of an OPTIONAL mirror attribute table and accept > Ron's modifications. I'd like to propose one MINOR change, myself... > > Rather than > -- The jmMirrorAttrTable provides efficient access to all of the > -- attributes that an implementation supports, sorted by attribute > -- type (traditional SNMP MIB access), rather than being sorted by > -- job set and job index (modern object-oriented access) as in the > -- analogous jmAttributeTable. > > I request deletion of the word "efficient" in the above. I think, > when we developed the tables we have, we did so because we felt it > was efficient. I think both methods are efficient based on > different perspectives and, therefor, there is no need to > embellish the paragraph. > > > Harry Lewis - IBM Printing Systems > harryl@us.ibm.com > > > > jmp-owner@pwg.org on 11/01/98 10:26:53 PM > Please respond to jmp-owner@pwg.org > To: hastings@cp10.es.xerox.com > cc: jmp@pwg.org > Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribu > > > Tom, > > I support your proposal to add the optional mirror attribute table to the > Job MIB. However, I would like to suggest the following text in place of > your proposed text. My changes eliminate much of the very repetitive text > that was included in your original draft. > > Also, you state that section 3.3 contains a description of > jmMirrorAttrTable, but you did not provide any changes to this section > with this description. (My revised text still contains this reference.) > > > Ron Bergman > Dataproducts Corp. > > > > ------------------------------------------------------------------------ > -- The Mirror Attribute Group (OPTIONAL) > > -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. > -- > -- Implementation of the objects in this group is OPTIONAL. > -- See Section 3.1 entitled 'Conformance Considerations'. > -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. > -- > -- The jmMirrorAttrTable provides efficient access to all of the > -- attributes that an implementation supports, sorted by attribute > -- type (traditional SNMP MIB access), rather than being sorted by > -- job set and job index (modern object-oriented access) as in the > -- analogous jmAttributeTable. > > jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } > > jmMirrorAttrTable OBJECT-TYPE > SYNTAX SEQUENCE OF JmAttributeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The jmMirrorAttrTable is an OPTIONAL table which provides > identical attributes to the jmAttributeTable but with a > different index structure. See jmAttributeTable for further > details. > > See Section 3.3 entitled 'The Attribute Mechanism' for a > description of the jmMirrorAttrTable." > ::= { jmMirror 1 } > > jmMirrorAttrEntry OBJECT-TYPE > SYNTAX JmMirrorAttrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The attributes that represent information about each job > and documents or resources required and/or consumed. > > Each entry in jmMirrorAttrTable is a per-attribute entry with a > primary index for each type of attribute (jmMirrorAttrTypeIndex) > that a job can have and secondary indices which specify job > set (jmJobSetIndex), job instance (jmJobIndex), and attribute > instance (jmMirrorAttrInstanceIndex). > > An agent which implements the jmMirrorAttrTable SHALL create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, > jmMirrorAttrInstanceIndex } > ::= { jmMirrorAttrTable 1 } > > JmMirrorAttrEntry ::= SEQUENCE { > jmMirrorAttrTypeIndex JmAttributeTypeTC, > jmMirrorAttrInstanceIndex Integer32 (1..32767), > jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), > jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) > } > > jmMirrorAttrTypeIndex OBJECT-TYPE > SYNTAX JmAttributeTypeTC > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The type of attribute that this row entry represents. > > See jmAttributeTypeIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 1 } > > jmMirrorAttrInstanceIndex OBJECT-TYPE > SYNTAX Integer32 (1..32767) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The instance of attribute that this row entry represents. > > See jmAttributeInstanceIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 2 } > > jmMirrorAttrValueAsInteger OBJECT-TYPE > SYNTAX Integer32 (-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The integer value of the attribute. > > See jmAttributeValueAsInteger in jmAttributeTable for complete > description." > DEFVAL { -2 } -- default value is unknown(-2) > ::= { jmMirrorAttrEntry 3 } > > jmMirrorAttrValueAsOctets OBJECT-TYPE > SYNTAX OCTET STRING(SIZE(0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The octet string value of the attribute. > > See jmAttributeValueAsOctets in jmAttributeTable for complete > description." > DEFVAL { ''H } -- empty string > ::= { jmMirrorAttrEntry 4 } > > ------------------------------------------------------------------------ > [for placement in 'jmMIBCompliance' before the first OBJECT clause] > > GROUP jmMirrorAttrGroup > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > > ------------------------------------------------------------------------ > [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] > > jmMirrorAttrGroup OBJECT-GROUP > OBJECTS { > jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } > STATUS current > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > ::= { jmMIBGroups 5 } > > ------------------------------------------------------------------------ > > > > > > From imcdonal at eso.mc.xerox.com Mon Nov 2 17:31:12 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribu Message-ID: <9811022231.AA17097@snorkel.eso.mc.xerox.com> Ron and Harry, I agree with both of your clarifications. Ron, thanks for your editorial work for clarity. Thanks to you both for public support. Harry, what Tom and I said poorly was efficient access by either sort (jmMirrorAttributeTable for type and jmAttributeTable for job index). Your deletion was appropriate. Cheers, - Ira McDonald High North Inc 906-494-2434 From hastings at cp10.es.xerox.com Fri Nov 6 15:03:07 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute ta ble Message-ID: <918C79AB552BD211A2BD00805F15CE854B4AAB@x-crt-es-ms1.cp10.es.xerox.com> I agree with Harry and Ron to delete the word "efficient". I agree with Ron's shortening of the text. Always good to make it shorter. Yes, we need a short paragraph for Section 3.3. The only quibble is that we need to add back the phrase "for the same time". Else it isn't clear that rows in both tables have to come and go at the same time. See below. Should I edit this OPTIONAL table into the JMP MIB now or wait for discussion/agreement at the meeting next Tuesday? I'll be bringing ten copies to the meeting of the updated MIB with the other agreements we reached, so I could add this too. Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Monday, November 02, 1998 09:05 >To: Hastings, Tom N >Cc: jmp >Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribute >table > > >Tom, > >I support your proposal to add the optional mirror attribute >table to the >Job MIB. However, I would like to suggest the following text >in place of >your proposed text. My changes eliminate much of the very >repetitive text >that was included in your original draft. > >Also, you state that section 3.3 contains a description of >jmMirrorAttrTable, but you did not provide any changes to this section >with this description. (My revised text still contains this >reference.) > > > Ron Bergman > Dataproducts Corp. > > > >--------------------------------------------------------------- >--------- >-- The Mirror Attribute Group (OPTIONAL) > >-- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. >-- >-- Implementation of the objects in this group is OPTIONAL. >-- See Section 3.1 entitled 'Conformance Considerations'. >-- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. >-- >-- The jmMirrorAttrTable provides efficient access to all of the >-- attributes that an implementation supports, sorted by attribute >-- type (traditional SNMP MIB access), rather than being sorted by >-- job set and job index (modern object-oriented access) as in the >-- analogous jmAttributeTable. > >jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } > >jmMirrorAttrTable OBJECT-TYPE > SYNTAX SEQUENCE OF JmAttributeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The jmMirrorAttrTable is an OPTIONAL table which provides > identical attributes to the jmAttributeTable but with a > different index structure. See jmAttributeTable for further > details. > > See Section 3.3 entitled 'The Attribute Mechanism' for a > description of the jmMirrorAttrTable." > ::= { jmMirror 1 } > >jmMirrorAttrEntry OBJECT-TYPE > SYNTAX JmMirrorAttrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The attributes that represent information about each job > and documents or resources required and/or consumed. > > Each entry in jmMirrorAttrTable is a per-attribute entry with a > primary index for each type of attribute >(jmMirrorAttrTypeIndex) > that a job can have and secondary indices which specify job > set (jmJobSetIndex), job instance (jmJobIndex), and attribute > instance (jmMirrorAttrInstanceIndex). > > An agent which implements the jmMirrorAttrTable SHALL >create and > maintain a row in the jmMirrorAttrTable for each corresponding Replace the above line with: maintain a row in the jmMirrorAttrTable for the same time as each corresponding > row in the jmAttributeTable." > INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, > jmMirrorAttrInstanceIndex } > ::= { jmMirrorAttrTable 1 } > >JmMirrorAttrEntry ::= SEQUENCE { > jmMirrorAttrTypeIndex JmAttributeTypeTC, > jmMirrorAttrInstanceIndex Integer32 (1..32767), > jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), > jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) >} > >jmMirrorAttrTypeIndex OBJECT-TYPE > SYNTAX JmAttributeTypeTC > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The type of attribute that this row entry represents. > > See jmAttributeTypeIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 1 } > >jmMirrorAttrInstanceIndex OBJECT-TYPE > SYNTAX Integer32 (1..32767) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The instance of attribute that this row entry represents. > > See jmAttributeInstanceIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 2 } > >jmMirrorAttrValueAsInteger OBJECT-TYPE > SYNTAX Integer32 (-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The integer value of the attribute. > > See jmAttributeValueAsInteger in jmAttributeTable for complete > description." > DEFVAL { -2 } -- default value is unknown(-2) > ::= { jmMirrorAttrEntry 3 } > >jmMirrorAttrValueAsOctets OBJECT-TYPE > SYNTAX OCTET STRING(SIZE(0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The octet string value of the attribute. > > See jmAttributeValueAsOctets in jmAttributeTable for complete > description." > DEFVAL { ''H } -- empty string > ::= { jmMirrorAttrEntry 4 } > >--------------------------------------------------------------- >--------- >[for placement in 'jmMIBCompliance' before the first OBJECT clause] > > GROUP jmMirrorAttrGroup > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL >create and > maintain a row in the jmMirrorAttrTable for each corresponding Replace the above line with: maintain a row in the jmMirrorAttrTable for the same time as each corresponding > row in the jmAttributeTable." > >--------------------------------------------------------------- >--------- >[for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] > >jmMirrorAttrGroup OBJECT-GROUP > OBJECTS { > jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } > STATUS current > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL >create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > ::= { jmMIBGroups 5 } > >--------------------------------------------------------------- >--------- > > > > From rbergma at dpc.com Fri Nov 6 15:32:33 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute ta ble In-Reply-To: <918C79AB552BD211A2BD00805F15CE854B4AAB@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, Please add the mirror table to the draft and we can discuss further next week. As far as ther phrase "for the same time" being necessary, I disagree. In re-reading the text I don't see how it could interpreted any other way without this phrase. Again, we can discuss next week. Ron Bergman Dataproducts Corp. On Fri, 6 Nov 1998, Hastings, Tom N wrote: > I agree with Harry and Ron to delete the word "efficient". > > I agree with Ron's shortening of the text. Always good to make it shorter. > > Yes, we need a short paragraph for Section 3.3. > > The only quibble is that we need to add back the phrase "for the same time". > Else it isn't clear that rows in both tables have to come and go at the same > time. See below. > > Should I edit this OPTIONAL table into the JMP MIB now or wait for > discussion/agreement at the meeting next Tuesday? > > I'll be bringing ten copies to the meeting of the updated MIB with the other > agreements we reached, so I could add this too. > > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Monday, November 02, 1998 09:05 > >To: Hastings, Tom N > >Cc: jmp > >Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribute > >table > > > > > >Tom, > > > >I support your proposal to add the optional mirror attribute > >table to the > >Job MIB. However, I would like to suggest the following text > >in place of > >your proposed text. My changes eliminate much of the very > >repetitive text > >that was included in your original draft. > > > >Also, you state that section 3.3 contains a description of > >jmMirrorAttrTable, but you did not provide any changes to this section > >with this description. (My revised text still contains this > >reference.) > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > >--------------------------------------------------------------- > >--------- > >-- The Mirror Attribute Group (OPTIONAL) > > > >-- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. > >-- > >-- Implementation of the objects in this group is OPTIONAL. > >-- See Section 3.1 entitled 'Conformance Considerations'. > >-- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. > >-- > >-- The jmMirrorAttrTable provides efficient access to all of the > >-- attributes that an implementation supports, sorted by attribute > >-- type (traditional SNMP MIB access), rather than being sorted by > >-- job set and job index (modern object-oriented access) as in the > >-- analogous jmAttributeTable. > > > >jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } > > > >jmMirrorAttrTable OBJECT-TYPE > > SYNTAX SEQUENCE OF JmAttributeEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The jmMirrorAttrTable is an OPTIONAL table which provides > > identical attributes to the jmAttributeTable but with a > > different index structure. See jmAttributeTable for further > > details. > > > > See Section 3.3 entitled 'The Attribute Mechanism' for a > > description of the jmMirrorAttrTable." > > ::= { jmMirror 1 } > > > >jmMirrorAttrEntry OBJECT-TYPE > > SYNTAX JmMirrorAttrEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The attributes that represent information about each job > > and documents or resources required and/or consumed. > > > > Each entry in jmMirrorAttrTable is a per-attribute entry with a > > primary index for each type of attribute > >(jmMirrorAttrTypeIndex) > > that a job can have and secondary indices which specify job > > set (jmJobSetIndex), job instance (jmJobIndex), and attribute > > instance (jmMirrorAttrInstanceIndex). > > > > An agent which implements the jmMirrorAttrTable SHALL > >create and > > maintain a row in the jmMirrorAttrTable for each corresponding > Replace the above line with: > > maintain a row in the jmMirrorAttrTable for the same time as each > corresponding > > > row in the jmAttributeTable." > > INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, > > jmMirrorAttrInstanceIndex } > > ::= { jmMirrorAttrTable 1 } > > > >JmMirrorAttrEntry ::= SEQUENCE { > > jmMirrorAttrTypeIndex JmAttributeTypeTC, > > jmMirrorAttrInstanceIndex Integer32 (1..32767), > > jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), > > jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) > >} > > > >jmMirrorAttrTypeIndex OBJECT-TYPE > > SYNTAX JmAttributeTypeTC > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The type of attribute that this row entry represents. > > > > See jmAttributeTypeIndex in jmAttributeTable for complete > > description." > > ::= { jmMirrorAttrEntry 1 } > > > >jmMirrorAttrInstanceIndex OBJECT-TYPE > > SYNTAX Integer32 (1..32767) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The instance of attribute that this row entry represents. > > > > See jmAttributeInstanceIndex in jmAttributeTable for complete > > description." > > ::= { jmMirrorAttrEntry 2 } > > > >jmMirrorAttrValueAsInteger OBJECT-TYPE > > SYNTAX Integer32 (-2..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The integer value of the attribute. > > > > See jmAttributeValueAsInteger in jmAttributeTable for complete > > description." > > DEFVAL { -2 } -- default value is unknown(-2) > > ::= { jmMirrorAttrEntry 3 } > > > >jmMirrorAttrValueAsOctets OBJECT-TYPE > > SYNTAX OCTET STRING(SIZE(0..63)) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The octet string value of the attribute. > > > > See jmAttributeValueAsOctets in jmAttributeTable for complete > > description." > > DEFVAL { ''H } -- empty string > > ::= { jmMirrorAttrEntry 4 } > > > >--------------------------------------------------------------- > >--------- > >[for placement in 'jmMIBCompliance' before the first OBJECT clause] > > > > GROUP jmMirrorAttrGroup > > DESCRIPTION > > "The mirror attribute group (sorted by attribute type). > > Implementation of this group is OPTIONAL. > > > > An agent which implements the jmMirrorAttrTable SHALL > >create and > > maintain a row in the jmMirrorAttrTable for each corresponding > Replace the above line with: > > maintain a row in the jmMirrorAttrTable for the same time as each > corresponding > > > > row in the jmAttributeTable." > > > >--------------------------------------------------------------- > >--------- > >[for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] > > > >jmMirrorAttrGroup OBJECT-GROUP > > OBJECTS { > > jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } > > STATUS current > > DESCRIPTION > > "The mirror attribute group (sorted by attribute type). > > Implementation of this group is OPTIONAL. > > > > An agent which implements the jmMirrorAttrTable SHALL > >create and > > maintain a row in the jmMirrorAttrTable for each corresponding > > row in the jmAttributeTable." > > ::= { jmMIBGroups 5 } > > > >--------------------------------------------------------------- > >--------- > > > > > > > > > From hastings at cp10.es.xerox.com Mon Nov 9 17:59:10 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> I've posted JMP MIB V1.3 - with IESG fixes and mirror table Message-ID: <918C79AB552BD211A2BD00805F15CE854B4CA4@x-crt-es-ms1.cp10.es.xerox.com> I haven't had time to compile it or produce a .txt form: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf I'll bring 10 copies to the meeting tomorrow. Here is the change history: 1.1 Changes to produce version 1.3, dated November 8, 1998 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.3, dated November 8, 1998: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. Tom Hastings (310) 333-6413 From don at lexmark.com Fri Nov 20 15:20:51 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: Maui Meeting Message-ID: <199811202024.AA18677@interlock2.lexmark.com> At the request of Ron Bergman and Harry Lewis, there are no MIB meetings planned for Maui. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** kpalmer%duplousa.com@interlock.lexmark.com on 11/19/98 08:02:43 PM Please respond to kpalmer%duplousa.com@interlock.lexmark.com To: Don Wright@LEXMARK cc: Subject: Maui Meeting Don: Do you know what days and times we will have the MIB meetings? Thank you Kevin Palmer Duplo USA Corp. From harryl at us.ibm.com Fri Nov 20 15:39:55 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 13:59:58 2009 Subject: JMP> Re: PMP> Re: Maui Meeting Message-ID: <5030100028732577000002L072*@MHS> No MIB meetings, as such... but, as I pointed out in Tucson... there was a high likelihood that we would be addressing the Printer-Finisher interface. While this is not a MIB meeting (Don is correct)... it will likely be of interest to anyone who has been involved in the Printer, Finisher and Job MIB's, in the past. The agenda for Printer-Finisher interface in January is not set, yet... but, due to an expected large turn out overlaying with IEEE1394 on Thursday is under consideration. Harry Lewis - IBM Printing Systems harryl@us.ibm.com pmp-owner@pwg.org on 11/20/98 01:27:57 PM Please respond to pmp-owner@pwg.org To: kpalmer@duplousa.com cc: jmp@pwg.org, pmp@pwg.org, fin@pwg.org Subject: PMP> Re: Maui Meeting At the request of Ron Bergman and Harry Lewis, there are no MIB meetings planned for Maui. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** kpalmer%duplousa.com@interlock.lexmark.com on 11/19/98 08:02:43 PM Please respond to kpalmer%duplousa.com@interlock.lexmark.com To: Don Wright@LEXMARK cc: Subject: Maui Meeting Don: Do you know what days and times we will have the MIB meetings? Thank you Kevin Palmer Duplo USA Corp. From rbergma at dpc.com Mon Nov 23 11:08:04 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Object to Indicate MIB Revision Message-ID: An additional object for the Job MIB, that would indicate the version of the MIB implemented, was discussed at the Tucson meeting. Now two weeks later there has not been a formal proposal submitted to the mail list. Upon further pondering of the proposal, I have concluded that this additional object would have marginal value. (No other MIB, that I am aware of, includes such an object.) I would like to get this project back on track and submit the updated document to the IESG as soon as possible. I do not want this effort to turn into a long term research project. I suggest that the document be frozen as presented in Tucson and the last call start immediately. Comments? Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Mon Nov 23 12:41:34 1998 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 13:59:58 2009 Subject: JMP> Object to Indicate MIB Revision Message-ID: <872566C5.00612AEC.00@us.ibm.com> I agree with Ron. The version was an attempt to figure a way to add the "mirror" table and make it mandatory. I propose this be handled in a future RFC, if necessary which can, at that time, add the version. Meanwhile, the mirror table can be optional. Harry Lewis - IBM Printing Systems harryl@us.ibm.com From hastings at cp10.es.xerox.com Mon Nov 23 12:54:53 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Object to Indicate MIB Revision Message-ID: <918C79AB552BD211A2BD00805F15CE85606AB4@x-crt-es-ms1.cp10.es.xerox.com> Sorry not to have made the proposal for the new version group sooner, but as editor of the IPP Model document, I have had my hands full getting that out by the deadline of last Wednesday. We seem to have forgotten the other object in this new group that we agreed to at the meeting, which is very useful to applications: A BITS vector that indicates which attributes have been implemented. Then an application can know whether to ever expect certain attributes to appear or not. I agree that we don't want to turn the JMP MIB into a research project. On the other hand, our developers had previously suggested just such a BITS vector, so I was very supportive of the proposal when it was brought up at the Tucson meeting. I'll make the proposal today. Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Monday, November 23, 1998 08:08 >To: jmp@pwg.org >Subject: JMP> Object to Indicate MIB Revision > > >An additional object for the Job MIB, that would indicate the >version of >the MIB implemented, was discussed at the Tucson meeting. Now >two weeks >later there has not been a formal proposal submitted to the mail list. > >Upon further pondering of the proposal, I have concluded that this >additional object would have marginal value. (No other MIB, that I am >aware of, includes such an object.) > >I would like to get this project back on track and submit the updated >document to the IESG as soon as possible. I do not want this effort to >turn into a long term research project. > >I suggest that the document be frozen as presented in Tucson >and the last >call start immediately. > >Comments? > > > Ron Bergman > Dataproducts Corp. > > From hastings at cp10.es.xerox.com Wed Nov 25 15:42:22 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Job Monitoring MIB V1.3 posted Message-ID: <918C79AB552BD211A2BD00805F15CE85606D38@x-crt-es-ms1.cp10.es.xerox.com> I've posted the 1.3 JMP MIB as agreed in Tucson as: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf It compiles. The .mib file is the result of stripping the headers. If Ron agrees, it is ready for him to send out to the PWG-ANNOUNCE mailing list for PWG Last Call. The .txt file should be renamed to: draft-ietf-printmib-job-monitor-08.txt when we send it as an Internet-Draft. I did NOT post it in the Internet-Drafts directory yet on the PWG server and did NOT send it to the IETF. (The IETF isn't accepting I-Ds until after their meeting in December. Here is the change history: 1.1 Changes to produce version 1.3, dated November 8, 1998 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.3, dated November 8, 1998: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. 3. Added the MANDATORY jmSystemGroup that contains the jmSystemVersionString, jmSystemOptionSupport, and jmSystemAttributeSupport objects. Here is the new System Group that we discussed adding in Tucson to help a management application determine what parts of the MIB the agent was supporting: -- The System Group (MANDATORY) -- (This group was added in version 1.3 of this MIB). -- The jmMirrorAttrGroup consists entirely of objects that summarize -- the implementation of this MIB on a system. jmSystem OBJECT IDENTIFIER ::= { jobmonMIBObjects 6 } jmSystemVersionString OBJECT-TYPE SYNTAX JmUTF8StringTC MAX-ACCESS read-only STATUS current DESCRIPTION "The minor and minor version of this MIB implemented by this system. The format of the string SHALL be the ASCII major version number followed by an ASCII PERIOD (.), followed by the ASCII minor version number, i.e., '1.3' for this version." DEFVAL { '312E33'H } -- version 1.3 ::= { jmSystem 1 } jmSystemOptionSupport OBJECT-TYPE SYNTAX INTEGER(0..2147483647) -- biggest int 2**31 - 1 MAX-ACCESS read-only STATUS current DESCRIPTION "The options of the MIB specification that this implementation supports specified as a bit mask. The current set of values (which may be extended in the future) is given below: 1 : jmMirrorAttrGroup -- 2**0 OPTIONAL Example: An implementation supporting the jmMirrorAttrGroup would return an integer value of { 1 }. This object helps a management application determine which MIB options are supported in this system." DEFVAL { 0 } -- no options are required ::= { jmSystem 2 } jmSystemAttributeSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The attributes of the MIB that this implementation supports specified as a bit array. The value of this object is a sparse bit array in which bit n is present if attribute n is supported, where n is the value of the enumerated attribute type in the JmAttributeTypeTC used in jmAttributeTypeIndex (and the jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). The high order bit of the first octet in this octet string corresponds to an attribute type of 0 (reserved), i.e., Big Endian bit string. Compare with the BITS data type in SMIv2 [SMIv2-SMI] which has the same format but requires contiguous enumerated bits. Note: private attributes cannot be represented in this bit array because their enum values are in the range 2**30 to 2**31-1. See section 3.3.8. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a value of { '180001'H }. This object helps a management application determine which attributes MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 3 } Tom Hastings (310) 333-6413 From hastings at cp10.es.xerox.com Mon Dec 14 18:47:58 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 13:59:58 2009 Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE8572F270@x-crt-es-ms1.cp10.es.xerox.com> We held a Xerox-wide design review the proposed version 1.3 of the PWG Job Monitoring MIB that included a number of client-side developers as well as agent developers. We believe that the single bit array, jmSystemAttributeSupport, indicating attribute support should be replaced with three bit arrays: 1) A bit array specifying which supported attributes can contain meaningful integer data. 2) A bit array specifying which supported attributes can contain meaningful string data. 3) A bit array specifying which supported attributes can have more than one integer or more than one string value. There are two main areas of concern regarding the use of "dictionary" or attribute defining MIBs. First is the efficiency with which attribute values can be requested and obtained from the device and second is the ability to create generic management middleware that can be reused when the MIB is extended with additional attributes and can be used with different management applications that use different combinations of attributes. Such middleware obtains all of the attributes and keeps a local copy of the attributes updated as the device runs. Any management application then deals with the client-side local copy by calling the client-side management middleware for any combination of attributes which are returned immediately without querying the device. Some items of note which should be considered in the following discussion are: 1) Most management applications must support SNMPv1 and SNMPv2 so that relying on a getBulk type operation is not viable. 2) Most management applications support multiple SNMP protocol stacks some of which have quite small packet size limits such as 480 octets so relying on a maximum size of more than that is not viable. One of the major concerns of many management applications is the minimization of network traffic and a major factor in determining the amount of traffic is the number of strings to be retrieved. The reason for this is due to the fact that strings can be fairly long, up to 63 octets. Couple this with the limited packet size available and it is easily seen that if a large number of strings are to be retrieved then a large number of packets will be required. At most only 6 strings can be requested in a single packet, else there is the risk of not all of the data fitting in the packet. This is because each string can be up to 63 octets and the OID for each string can be around 15-20 octets, say around 80 as a maximum. 484 divided by 80 is 6 strings maximum. If only a single bit array is used then both the integer and string values will have to be requested for all of the supported attributes. Since most of the string values will be NULL this results in a large number of packets with unnecessary data (the null strings). With an indicator of which attributes can actually have valid string data then only those attributes need to be requested and the number of needed packets can be optimized. This same argument applies to integers as well, although, to a lesser degree since 24 or so integers can be requested in a single packet. Being able to request this information from the device rather than encoding it directly into management application middleware makes the application middleware more robust, generic and re-usable. Encoding the information directly into the application middleware that an application needs means that the middleware can not be used with any application. It also means that if new attributes are added to a MIB then the application middleware will have to be modified to accommodate them. Neither of these situations is desirable from a software design and product deployment point-of-view. Adding the bit array that indicates which attributes might have more than one value and which ones cannot, means that the management application knows which values should be retrieved with several GetNext operations in order to pick up all the values and which only need one direct Get. While the specification indicates which attribute MAY have multiple values, many implementations MAY only actually implement one value. For example, the number of fileName or documentName attribute values per job MAY only have a single value for many implementations that only support one document per job, though multiple values are allowed. The same for mediumRequested, etc. So the third bit array indicates which attributes could have more than one value for that implementation. Having these three bit arrays also allows management middleware to obtain attribute extensions from a device that were registered after the management middleware was shipped. Only the management application needs updating that wants to take advantage of the newly registered attributes. Since these bit arrays are all read-only and never change while the device operates, they are very low cost in implementation and can be put into ROM. While we share the group's concern about "creeping elegance" and "mission creep" and want to see the PWG Job Monitoring MIB approved, we believe that these three bit arrays are the end. There does not seem to be any other support information about an implementation that could be added to the new System Group. So we believe that this addition would be the end. We have produced complete compilable alternatives to V1.3 and stored them in a sub-directory of the usual place: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .pdf Here are the relevant changes: In Section 3.3.8 Attribute Specification update the paragraphs on the bit array support: A management application can determine which attributes are supported and whether the integer and/or the octet string values are supported with meaningful value by querying the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects, respectively. Management applications can also determine which supported attributes might support more than one integer value or more than one octet string value by querying jmSystemAttrMultiRowSupport. These support bits are indicated in hex for each range in the line starting with "support bits starting:". Note: these objects permit a management application to determine the degree of support, even when there are no jobs present in the system. They also permit management middleware to fetch all attribute values for all jobs, including future extensions, and keep them updated for one or more management applications at the same time. Replace the jmSystemAttributeSupport bit array object with the following three bit array objects: jmSystemAttrIntegerSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful integer values. The value of this object is a sparse bit array in which bit n is a 1 if attribute n is supported with the jmAttributeValueAsInteger object with meaningful values, where n is the value of the enumerated attribute type in the JmAttributeTypeTC used in jmAttributeTypeIndex (and the jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned with a '- 1'(other) or '-2'(unknown) value. The high order bit of the first octet in this octet string corresponds to an attribute type of 0 (reserved), i.e., the bit string uses the Big Endian numbering convention. Compare with the BITS data type in SMIv2 [SMIv2-SMI] which has the same format but requires contiguous enumerated bits. Trailing octets in the octet string that contain only zero bits MUST NOT be returned. Note: private attributes cannot be represented in this bit array because their enum values are in the range 2**30 to 2**31-1. See section 3.3.8. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a one-octet string value of { '18'H }, since jobName is an octet string value, not an integer value. This object helps a management application determine which attributes with meaningful integer values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 3 } jmSystemAttrOctetsSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful octet string values. The format and semantics of this object is the same as jmSystemAttrIntegerSupport, except that bit n indicates that attribute n supports the jmAttributeValueAsOctets object with meaningful values, instead of the jmAttributeValueAsInteger object. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned as a zero-length octet string value. If an implementation supports both jmAttributeValueAsInteger and jmAttributeValueAsOctets with meaningful values for attribute n, bit n MUST appear in both bit array objects with a 1 value. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a three-octet string value of { '000001'H }, since jobStateReasons2 and jobStateReasons3 are integer values, not octet string values. This object helps a management application determine which attributes with meaningful octet string values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 4 } jmSystemAttrMultiRowSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which MULTI-ROW attributes of the MIB this implementation supports with multiple integer values and/or multiple octet string values. The format of this object is the same as the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects. Bit n MUST be 1, if attribute n is actually supported with more than one integer and/or more than one octet string value. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported, is always returned as a single integer value, or as a single octet string value. For every bit n that is a 1 in this bit array, there MUST be a corresponding 1 for bit n in either jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, or both. Example: Consider an implementation supporting: (a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW integer attributes (b) the jobName(23) SINGLE-ROW octet string attribute (c) more than one integer value for the mediumRequested(170) and mediumConsumed(171) MULTI-ROW attributes AND (d) more than one octet string value for the fileName(34), documentName(35), and mediumConsumed(171) MULTI-ROW attributes (e) no octet string values for mediumRequested(170). Such an implementation would return: jmSystemAttrIntegerSupport 22 octets: { '18000000 00000000 00000000 00000000 00000000 0030'H } jmSystemAttrOctetsSupport 22 octets: { '00000100 30000000 00000000 00000000 00000000 0010'H } jmSystemAttrMultiRowSupport 22 octets: { '00000000 30000000 00000000 00000000 00000000 0030'H } Example: Consider an implementation that supports the fileName(34) MULTI-ROW attribute, but does not support more than one document per job. Such an implementation would NOT return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since such an implementation would never return more than one fileName value for a job. It would return a zero-length string, since it never returns more than one value. This object helps a management application determine which attributes may return more than one integer value or more than one octet string value on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 5 } Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike Elvers, Ang Caruso, Joe Filion (310) 333-6413 From rbergma at dpc.com Tue Dec 22 10:41:31 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 13:59:58 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: I am requesting a formal ballot regarding the recent request from Xerox to expand the object jmSystemAttributeSupport to three objects. Since this is a very last minute change, it is very important that all who have participated in this project review this change carefully. Please return the following ballot: Name: ___________________________________ Company: ________________________________ ___ I support this proposed change ___ I reject this proposed change ___ I abstain from voting for the following reason: ___________________________________________________________ Because the holidays will soon be here, I am setting the deadline to January 13th. So we should have a final vote prior to the Maui meeting. I encourage everyone to vote! Ron Bergman Dataproducts Corp. ---------- Forwarded message ---------- Date: Mon, 14 Dec 1998 15:47:58 -0800 From: "Hastings, Tom N" To: jmp Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call We held a Xerox-wide design review the proposed version 1.3 of the PWG Job Monitoring MIB that included a number of client-side developers as well as agent developers. We believe that the single bit array, jmSystemAttributeSupport, indicating attribute support should be replaced with three bit arrays: 1) A bit array specifying which supported attributes can contain meaningful integer data. 2) A bit array specifying which supported attributes can contain meaningful string data. 3) A bit array specifying which supported attributes can have more than one integer or more than one string value. There are two main areas of concern regarding the use of "dictionary" or attribute defining MIBs. First is the efficiency with which attribute values can be requested and obtained from the device and second is the ability to create generic management middleware that can be reused when the MIB is extended with additional attributes and can be used with different management applications that use different combinations of attributes. Such middleware obtains all of the attributes and keeps a local copy of the attributes updated as the device runs. Any management application then deals with the client-side local copy by calling the client-side management middleware for any combination of attributes which are returned immediately without querying the device. Some items of note which should be considered in the following discussion are: 1) Most management applications must support SNMPv1 and SNMPv2 so that relying on a getBulk type operation is not viable. 2) Most management applications support multiple SNMP protocol stacks some of which have quite small packet size limits such as 480 octets so relying on a maximum size of more than that is not viable. One of the major concerns of many management applications is the minimization of network traffic and a major factor in determining the amount of traffic is the number of strings to be retrieved. The reason for this is due to the fact that strings can be fairly long, up to 63 octets. Couple this with the limited packet size available and it is easily seen that if a large number of strings are to be retrieved then a large number of packets will be required. At most only 6 strings can be requested in a single packet, else there is the risk of not all of the data fitting in the packet. This is because each string can be up to 63 octets and the OID for each string can be around 15-20 octets, say around 80 as a maximum. 484 divided by 80 is 6 strings maximum. If only a single bit array is used then both the integer and string values will have to be requested for all of the supported attributes. Since most of the string values will be NULL this results in a large number of packets with unnecessary data (the null strings). With an indicator of which attributes can actually have valid string data then only those attributes need to be requested and the number of needed packets can be optimized. This same argument applies to integers as well, although, to a lesser degree since 24 or so integers can be requested in a single packet. Being able to request this information from the device rather than encoding it directly into management application middleware makes the application middleware more robust, generic and re-usable. Encoding the information directly into the application middleware that an application needs means that the middleware can not be used with any application. It also means that if new attributes are added to a MIB then the application middleware will have to be modified to accommodate them. Neither of these situations is desirable from a software design and product deployment point-of-view. Adding the bit array that indicates which attributes might have more than one value and which ones cannot, means that the management application knows which values should be retrieved with several GetNext operations in order to pick up all the values and which only need one direct Get. While the specification indicates which attribute MAY have multiple values, many implementations MAY only actually implement one value. For example, the number of fileName or documentName attribute values per job MAY only have a single value for many implementations that only support one document per job, though multiple values are allowed. The same for mediumRequested, etc. So the third bit array indicates which attributes could have more than one value for that implementation. Having these three bit arrays also allows management middleware to obtain attribute extensions from a device that were registered after the management middleware was shipped. Only the management application needs updating that wants to take advantage of the newly registered attributes. Since these bit arrays are all read-only and never change while the device operates, they are very low cost in implementation and can be put into ROM. While we share the group's concern about "creeping elegance" and "mission creep" and want to see the PWG Job Monitoring MIB approved, we believe that these three bit arrays are the end. There does not seem to be any other support information about an implementation that could be added to the new System Group. So we believe that this addition would be the end. We have produced complete compilable alternatives to V1.3 and stored them in a sub-directory of the usual place: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .pdf Here are the relevant changes: In Section 3.3.8 Attribute Specification update the paragraphs on the bit array support: A management application can determine which attributes are supported and whether the integer and/or the octet string values are supported with meaningful value by querying the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects, respectively. Management applications can also determine which supported attributes might support more than one integer value or more than one octet string value by querying jmSystemAttrMultiRowSupport. These support bits are indicated in hex for each range in the line starting with "support bits starting:". Note: these objects permit a management application to determine the degree of support, even when there are no jobs present in the system. They also permit management middleware to fetch all attribute values for all jobs, including future extensions, and keep them updated for one or more management applications at the same time. Replace the jmSystemAttributeSupport bit array object with the following three bit array objects: jmSystemAttrIntegerSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful integer values. The value of this object is a sparse bit array in which bit n is a 1 if attribute n is supported with the jmAttributeValueAsInteger object with meaningful values, where n is the value of the enumerated attribute type in the JmAttributeTypeTC used in jmAttributeTypeIndex (and the jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned with a '- 1'(other) or '-2'(unknown) value. The high order bit of the first octet in this octet string corresponds to an attribute type of 0 (reserved), i.e., the bit string uses the Big Endian numbering convention. Compare with the BITS data type in SMIv2 [SMIv2-SMI] which has the same format but requires contiguous enumerated bits. Trailing octets in the octet string that contain only zero bits MUST NOT be returned. Note: private attributes cannot be represented in this bit array because their enum values are in the range 2**30 to 2**31-1. See section 3.3.8. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a one-octet string value of { '18'H }, since jobName is an octet string value, not an integer value. This object helps a management application determine which attributes with meaningful integer values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 3 } jmSystemAttrOctetsSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful octet string values. The format and semantics of this object is the same as jmSystemAttrIntegerSupport, except that bit n indicates that attribute n supports the jmAttributeValueAsOctets object with meaningful values, instead of the jmAttributeValueAsInteger object. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned as a zero-length octet string value. If an implementation supports both jmAttributeValueAsInteger and jmAttributeValueAsOctets with meaningful values for attribute n, bit n MUST appear in both bit array objects with a 1 value. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a three-octet string value of { '000001'H }, since jobStateReasons2 and jobStateReasons3 are integer values, not octet string values. This object helps a management application determine which attributes with meaningful octet string values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 4 } jmSystemAttrMultiRowSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which MULTI-ROW attributes of the MIB this implementation supports with multiple integer values and/or multiple octet string values. The format of this object is the same as the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects. Bit n MUST be 1, if attribute n is actually supported with more than one integer and/or more than one octet string value. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported, is always returned as a single integer value, or as a single octet string value. For every bit n that is a 1 in this bit array, there MUST be a corresponding 1 for bit n in either jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, or both. Example: Consider an implementation supporting: (a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW integer attributes (b) the jobName(23) SINGLE-ROW octet string attribute (c) more than one integer value for the mediumRequested(170) and mediumConsumed(171) MULTI-ROW attributes AND (d) more than one octet string value for the fileName(34), documentName(35), and mediumConsumed(171) MULTI-ROW attributes (e) no octet string values for mediumRequested(170). Such an implementation would return: jmSystemAttrIntegerSupport 22 octets: { '18000000 00000000 00000000 00000000 00000000 0030'H } jmSystemAttrOctetsSupport 22 octets: { '00000100 30000000 00000000 00000000 00000000 0010'H } jmSystemAttrMultiRowSupport 22 octets: { '00000000 30000000 00000000 00000000 00000000 0030'H } Example: Consider an implementation that supports the fileName(34) MULTI-ROW attribute, but does not support more than one document per job. Such an implementation would NOT return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since such an implementation would never return more than one fileName value for a job. It would return a zero-length string, since it never returns more than one value. This object helps a management application determine which attributes may return more than one integer value or more than one octet string value on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 5 } Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike Elvers, Ang Caruso, Joe Filion (310) 333-6413 From Angelo.Caruso at usa.xerox.com Mon Jan 5 10:33:56 1998 From: Angelo.Caruso at usa.xerox.com (Caruso, Angelo ) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank last p In-Reply-To: Re: JMP> URGENT: Should impressions include blank last p> Message-ID: <9712300143.AA18672@snorkel.eso.mc.xerox.com> Tom, I disagree that the impressions counters are intended only for monitoring. For monitoring, you only need the jobImpressionsCompleted and jobImpressionsRequested counters. The fullColorImpressionsCompleted and highlightColorImpressionsCompleted attributes were proposed specifically for accounting with color capable devices. Our assumption was that impressions would be more useful for accounting since they are more accurate than sheets. Though I am not an accounting expert, I think providing the impression counters gives an accounting application developer added flexibility (e.g. so that billing for blank sides could be made optional depending on the requirements of the customer). I also agree with Bill Wagner that complete accuracy would require measuring colorant use per side. We thought about this and decided it was way too complicated for the job MIB. Our compromise solution was to propose the fullColor and highlightColor impressions counters. At any rate, it is clear that we need more input from real customers on their accounting requirements. For example, if most print shops charge one per-sheet rate for color devices and another rate for monochrome devices, then the color impressions counters aren't currently needed. But providing them offers customers a competitive edge in their billing methods since they can be more accurate. Thanks, Angelo -----Original Message----- From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] Sent: Thursday, December 18, 1997 10:21 PM To: XCMI Editors only Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last pageback sides or not? What about this proposal to recommend, but not require, that the back side of the last sheet not count for impressions? Alternatively, we could make a note that impressions is intended for monitoring, not accounting, and keep the definition of the number of passes past the marker, whether marks are made or not. Sheets is intended for accounting which in combination with the 'sides' attribute selects the rate. I believe this is what Kinkos does. Tom >X-Sender: spencerdr@vipmail.earthlink.net >Date: Thu, 18 Dec 1997 10:03:04 PST >To: "Wagner, William" >From: David R Spencer >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include blank last > page back sides or not? >Cc: ipp@pwg.org >Sender: ipp-owner@pwg.org >X-MIME-Autoconverted: from quoted-printable to 8bit by garfield.cp10.es.xerox.com id LAA26719 > >Bill, > >I'm just monitoring the group, but isn't there a significant difference between blank pages within a document and documents in a duplex job with an odd number of pages causing the COMPLETELY blank back side of the last page to be counted? Almost all page printers include an option for not printing such completely blank pages, and I think the point about user concern is well taken. > >Therefore, perhaps the sentence in the definition of impression: >> If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. >should be: >If a two-sided document has an odd number of pages and there are no marks to be made on second side of the last sheet, the last sheet should count as one impression, instead of two, even if that sheet makes two passes through the marker. > >David R. Spencer > >Spencer & Associates Publishing, Ltd. >Three Giffard Way, Melville, NY 11747-2310 >david@spencer.com >1-516-367-6655 Fax:1-516-367-2878 >http://www.spencer.com >______________________________________________________________________ > > >>This was discussed in great detail at the LA meeting. If one agrees >>that the MIB is to provide information on what the printer does, which >>may not necessarily agree with what the rate structures may or may not >>be at a particular place at a particular time, then I think the >>contention that sending a sheet side through transfer and fixing steps >>constitutes making an impression. The question of how much colorant is >>put on that page is a separate one. If it is a single period, a fully >>colored page or a blank page, colorant use is a different characteristic >>from impression, and one which could be instrumented. >> >>In most page printers, the information that a page has no marking is not >>readily available. The page goes though the same processes, takes pretty >>much the same time and the same wear and tear on the mechanism. I >>suggest that, unless the printer has a way of separately ejecting such >>sheet sides, from a printer point of view, treating a blank side >>differently is an artificial distinction. >> >>The point may be moot. I am told that commercial duplication houses >>charge by the sheet, with perhaps a different sheet rate for duplex (but >>no distinction for blank sides). A large in-house reports person told >>me that there are no blank pages; there is a header or footer, a page >>number, or a "This page intentionally left blank" message. >> >>I suggest that a measure of importance from those actually concerned >>with the accounting be obtained before the MIB imposes the derivation of >>another parameter on the printer. >> >>W. A. Wagner (Bill Wagner) >>OSICOM/DPI >> >>> -----Original Message----- >>> From: Jay Martin [SMTP:jkm@underscore.com] >>> Sent: Wednesday, December 17, 1997 11:50 PM >>> To: Tom Hastings >>> Cc: jmp@pwg.org; ipp@pwg.org >>> Subject: IPP> Re: JMP> URGENT: Should impressions include blank >>> last page back sides or not? >>> >>> Sorry, but I must agree with Angelo Caruso with the position >>> that most folks are going to be pretty upset if they are >>> charged for blanks sides of sheets. Can't say that I like >>> that idea at all. >>> >>> ...jay >>> >>> ---------------------------------------------------------------------- >>> -- JK Martin | Email: jkm@underscore.com -- >>> -- Underscore, Inc. | Voice: (603) 889-7000 -- >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- >>> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- >>> ---------------------------------------------------------------------- > > > > > From hastings at cp10.es.xerox.com Mon Jan 5 10:43:49 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted In-Reply-To: <9712300126.AA18611@snorkel.eso.mc.xerox.com> Message-ID: <3.0.1.32.19980105074349.011074d0@garfield> At 17:26 12/29/1997 PST, Ira Mcdonald x10962 wrote: >Hi Tom, > >Per earlier comments from David Perkins, please do NOT move all >the attribute descriptions up before the BEGIN statement. Just >make them all into ASN.1 comment lines in place (with "--" in >column 1), and remember to wrap a close-quote around the last >line of the general DESCRIPTION clause (in '...AttributeTypeTC'). > >Otherwise, an 'mstrip' output will remove all the attribute >descriptions (NOT good). Gee. That's too bad, because I've been trying to avoid hand editing the .doc file after reformatting for fixed pitch font. Is there any other way around this, such as dividing the DESCRIPTION into two parts, with each part having its own "....". E.g.: DESCRIPTION "..... ...." ".... ...." Or does the syntax require that there be only one pair of "..."? Since this problem only appeared this last version, we must have just crossed the limit for the SNICng compiler for the maximum length of compiled string. Tom > >No, I didn't have any trouble running 'mstrip' on your posted >version. Hmmm. So its the Sun version of mstrip that is having the problem stripping the headers from the .txt version that I produced at home on Windows 95. > >Also, I forgot to further pursue the Epilogue warning on the >assignment in the MODULE-IDENTITY macro. I'll try to get back >to this later this week or next week, as soon as I can. > >Cheers, >- Ira >--------------------------------- >>From hastings@cp10.es.xerox.com Mon Dec 29 17:45:20 1997 >Return-Path: >Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) > id AA18554; Mon, 29 Dec 97 17:45:19 EST >Received: from norman.cp10.es.xerox.com by zombi (4.1/SMI-4.1) > id AA26662; Mon, 29 Dec 97 17:40:10 EST >Received: from garfield.cp10.es.xerox.com (garfield.cp10.es.xerox.com [13.240.104.48]) > by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id OAA00115; > Mon, 29 Dec 1997 14:38:57 -0800 (PST) >Received: from dellxpi-11 (ppphastings [13.240.103.243]) > by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id OAA09541; > Mon, 29 Dec 1997 14:35:07 -0800 (PST) >Message-Id: <3.0.1.32.19971229143542.010a8100@garfield> >X-Sender: hastings@garfield >X-Mailer: Windows Eudora Pro Version 3.0.1 (32) >Date: Mon, 29 Dec 1997 14:35:42 -0800 >To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962), jmp@pwg.org >From: Tom Hastings >Subject: Re: JMP> RESEND: PWG Standard Job Monitoring MIB, V1, posted >In-Reply-To: <9712221501.AA17020@snorkel.eso.mc.xerox.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Status: R > >At 07:01 12/22/1997 PST, Ira Mcdonald x10962 wrote: >>Hi Tom, >> >>I commented out (as ASN.1 comments) the details of the attributes >>in the DESCRIPTION clause of JmAttributeTypeTC in this version >>of the Job Mon MIB and got a CLEAN compile with SMICng. > >Looks like I should move all the DESCRIPTION of each of the attributes >up front before the BEGIN into the section on attributes, since I got the >same error with SMICng on my Sun workstation. Since I have the >enum numbers duplicated in the description, the reader can still find each >attribute easily by the number and the table of contents and index will >refer to the moved section. > >By the way, did you have any difficulty removing the headers and footers >from the .txt version with the MSTRING program distributed with SMICng on the >PC? The version of mstring on the Sun was unable to strip the headers from >the .txt version that I posted. My test compile was with a previous version >that differed only in formatting. > >> >>I also got a small warning from Epilogue on the OID assignment >>statement in the MODULE-IDENTITY macro. I'll look at this >>more and experiment before commenting to the DL. > >I got it too, but I figured it was some problem with the Epilogue compiler, >but if you see a problem, let us know. > >> >>Lastly, the posted text file has 275 lines that are 73 characters >>long (not all are trailing blanks). After using the SMICng >>'mstrip' tool to extract the '.mib' file, there are still 164 lines >>that are 73 characters long. This does NOT meet the IETF rules >>for Internet-Drafts (or RFCs) and will need to be corrected >>in January. > >Yes, I discovered this too, so I need to make the right margin 1.4 inches >wide, instead of 1.3 (left, top, and bottome = 0.0). It looks like MS-WORD >now places the center of the character inside the margin, not the right >edge of the character. Strange. > >> >>Thanks for all the good work, >>- Ira McDonald (outside consultant at Xerox) >> >> > > > From harryl at us.ibm.com Mon Jan 5 11:41:12 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:13 2009 Subject: JMP> URGENT: Should impressions include blank last page In-Reply-To: URGENT: Should impressions include blank last page> Message-ID: <3.0.1.32.19980105074349.011074d0@garfield> We discussed this at length in LA. You may recall, I was the main propo= nent of accurate accounting (i.e. not counting blank impressions). In LA it was= established, however, that many, many print controllers would be unable= to discern a blank impression because the "page eject" command from whatev= er PDL is in use is still invoked. We also agreed that sheet based accounting = is more pragmatic except in the case of very high cost marker supplies. At and/or following LA, we even went to great length to come up with a clarified definition of an impression being a sheet side traversing the= marker path - whether or not marks were made. We had to do this to prevent cou= nting two impressions for every sheet of a simplex job. Even though I came out the shoot arguing for optimum accountability, I = was convinced in LA and remain convinced that the compromise described abov= e is a good one. I recall discussing an additional (optional) attribute for "n= umber of blank impressions" to accommodate devices that ARE able to detect and a= ccount for blanks, but don't remember if this has been included. I recommend we remain with these decisions. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 12/17/97 11:54:27 AM Please respond to jmp-owner@pwg.org @ internet To: jmp@pwg.org @ internet cc: szilles@Adobe.COM @ internet, ipp@pwg.org @ internet Subject: JMP> URGENT: Should impressions include blank last page back At the JMP meeting on 12/5, we agreed that the definitions of impressions would count the number of times a media side goes past the marker, even if there are no marks made. I think we agreed to that, becasue impressions is supposed to count after the sheet is stacked, so that the sheet counter doesn't know whet= her the back side of the last page (documents with an odd number of pages),= was marked or not, so we said that it SHALL count. Howver, for an accounting application, the customers may get pretty unhappy with having to pay for the final side they didn't use, as Angelo points out, when their document has an odd number of pages. URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: So how about RECOMMENDING (but not requiring) that the number of impres= sions for two-sided printing not include counting both sides of sheets marked= on only one side. It may be that the interpreter has to be involved in counting impressions, rather than the sheet counter in the stacker or m= aybe the implementation only worries about the last sheet and so there is ju= st an internal status bit that says whether a document has an odd number o= r an even number of sides in order to know whether to count the last sheet a= s 1 or 2 impressions. I suggest changing the sentence in the definition of impression: If a two-sided document has an odd number of pages, the last sheet stil= l counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. to: If a two-sided document has some sheets that only have marks on one sid= e (such as on the last sheet of a document with an odd-number of impressions), those sheets SHOULD count as one impression, instead of t= wo, even if that sheet makes two passes through the marker. BTW, the current definition of "impression" in the IPP Model is: 12.2.15 impressions An "impression" is the image (possibly many print-stream pages in diffe= rent configurations) imposed onto a single media page. So it seems that the IPP Job Model is in agreement with the following recommendation for the Job Mon MIB: The full definition of the term impressions (as sent yesterday) is for the Job Monitoring MIB: Impression: For a print job, an impression is the passage of the entir= e side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker= From rbergma at dpc.com Mon Jan 5 12:27:43 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> Some Comments on version 07 draft Message-ID: <3.0.1.32.19980105074349.011074d0@garfield> Tom, Job MIB *text* version 07 comments: 1. Page #2 is blank, is this intentional. 2. Proposed change to format of Job Collation Type tables in section 3.4. I believe that this format is much more readable. Job Collation Type = Uncollated Sheets jmJob- | impressions- | sheet- | sheet- Impressions- | Completed- | Completed- | Completed- Completed | CurrentCopy | CopyNumber | DocumentNumber ---------------+----------------+----------------+---------------- 0 | 0 | 0 | 0 1 | 1 | 1 | 1 2 | 1 | 2 | 1 3 | 1 | 3 | 1 4 | 2 | 1 | 1 5 | 2 | 2 | 1 6 | 2 | 3 | 1 7 | 3 | 1 | 1 8 | 3 | 2 | 1 9 | 3 | 3 | 1 10 | 1 | 1 | 2 11 | 1 | 2 | 2 12 | 1 | 3 | 2 13 | 2 | 1 | 2 14 | 2 | 2 | 2 15 | 2 | 3 | 2 16 | 3 | 1 | 2 17 | 3 | 2 | 2 18 | 3 | 3 | 2 I was not able to review the entire document since I was unable to read the doc version. I will try again to pull it from the PWG FTP server and review today. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Jan 5 16:25:58 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> URGENT: Should impressions include blank last page In-Reply-To: <5030300016521227000002L072*@MHS> Message-ID: <3.0.1.32.19980105132558.01013ea0@garfield> Here is the text that I've included in the draft based on the e-mail discussion (which agrees with Harry's suggestion to keep with the L.A. agreements and the subsequent e-mail discussion about how highlight and full color impressions are counted): Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression, as does highlight color. Impression counters count all kinds: monochrome, highlight color, and full process color, while full color counters only count full color impressions, and high light color counters only count high light color impressions. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". NOTE - Since impressions include blank sides, it is suggested that accounting application implementers consider charging for sheets, rather than impressions, possibly using the value of the sides attribute to select different charges for one-sided versus two-sided printing, since some users may think that impressions don't include blank sides. So I think our consensus is holding here. Tom At 08:41 01/05/1998 PST, Harry Lewis wrote: >We discussed this at length in LA. You may recall, I was the main proponent of >accurate accounting (i.e. not counting blank impressions). In LA it was >established, however, that many, many print controllers would be unable to >discern a blank impression because the "page eject" command from whatever PDL >is in use is still invoked. We also agreed that sheet based accounting is more >pragmatic except in the case of very high cost marker supplies. > >At and/or following LA, we even went to great length to come up with a >clarified definition of an impression being a sheet side traversing the marker >path - whether or not marks were made. We had to do this to prevent counting >two impressions for every sheet of a simplex job. > >Even though I came out the shoot arguing for optimum accountability, I was >convinced in LA and remain convinced that the compromise described above is a >good one. I recall discussing an additional (optional) attribute for "number of >blank impressions" to accommodate devices that ARE able to detect and account >for blanks, but don't remember if this has been >included. > >I recommend we remain with these decisions. > >Harry Lewis - IBM Printing Systems > > > > >jmp-owner@pwg.org on 12/17/97 11:54:27 AM >Please respond to jmp-owner@pwg.org @ internet >To: jmp@pwg.org @ internet >cc: szilles@Adobe.COM @ internet, ipp@pwg.org @ internet >Subject: JMP> URGENT: Should impressions include blank last page back > > >At the JMP meeting on 12/5, we agreed that the definitions of >impressions would count the number of times a media side goes past >the marker, even if there are no marks made. > >I think we agreed to that, becasue impressions is supposed to count >after the sheet is stacked, so that the sheet counter doesn't know whether >the back side of the last page (documents with an odd number of pages), >was marked or not, so we said that it SHALL count. > >Howver, for an accounting application, the customers may get pretty >unhappy with having to pay for the final side they didn't use, as >Angelo points out, when their document has an odd number of pages. > >URGENT: I NEED FEEDBACK FROM THE JMP LIST BY THURSDAY 12/18 EVENING. >HEARING NO OBJECTIONS I'M GOING FORWARD WITH THE FOLLOWING: > >So how about RECOMMENDING (but not requiring) that the number of impressions >for two-sided printing not include counting both sides of sheets marked on >only one side. It may be that the interpreter has to be involved in >counting impressions, rather than the sheet counter in the stacker or maybe >the implementation only worries about the last sheet and so there is just >an internal status bit that says whether a document has an odd number or an >even number of sides in order to know whether to count the last sheet as 1 >or 2 impressions. > >I suggest changing the sentence in the definition of impression: > >If a two-sided document has an odd number of pages, the last sheet still >counts as two impressions, if that sheet makes two passes through the >marker or the marker marks on both sides of a sheet in a single pass. > >to: > >If a two-sided document has some sheets that only have marks on one side >(such as on the last sheet of a document with an odd-number of >impressions), those sheets SHOULD count as one impression, instead of two, >even if that sheet makes two passes through the marker. > >BTW, the current definition of "impression" in the IPP Model is: > >12.2.15 impressions > >An "impression" is the image (possibly many print-stream pages in different >configurations) imposed onto a single media page. > >So it seems that the IPP Job Model is in agreement with the following >recommendation for the Job Mon MIB: > > >The full definition of the term impressions (as sent yesterday) is >for the Job Monitoring MIB: > >Impression: For a print job, an impression is the passage of the entire >side of a sheet by the marker, whether or not any marks are made and >independent of the number of passes that the side makes past the marker > > From rbergma at dpc.com Tue Jan 6 12:03:28 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> More comments on version 0.7 Message-ID: <3.0.1.32.19980105132558.01013ea0@garfield> Tom, Some of the additional problems I noticed in version 0.7. The line numbers are from the pdf file. Lines 802-804: -------------- ...(see section System Configurations for the Job Monitoring MIB entitled "System Configurations for the Job Monitoring MIB"). Change to: ...(see section entitled "System Configurations for the Job Monitoring MIB"). Lines 1102-1104: ---------------- The PWG will handle registration of additional enums after approving this standard is approved according to the procedures described in this section. Change to: The PWG will handle registration of additional enums after approving this standard, according to the procedures described in this section. Lines 2326-2327: ---------------- See section Monitoring Job Progress, entitled 'Monitoring Job Progress'. Change to: See section entitled 'Monitoring Job Progress'. Lines 2479-2480: ---------------- ...reset to 1 after the first sheet of each document and document copy in the job processed and stacked. Change to: ...reset to 1 after the first sheet of each document and document copy in the job is processed and stacked. A reference for the Job Submission Protocol Mapping document should be included in section 7.0 as RFC XXXX. The XXXX will be changed to the assigned number after we submit the documents. Also the reference to the IPP Model document should include RFC XXXX. And the reference to the Printer MIB update should be removed since this is work in process. (Unless an RFC number can be assigned prior to the release of the new Printer MIB.) I also noted that Harry Lewis is included both as an author and also as an "other participant". Looks like we are almost there! Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Tue Jan 6 20:37:22 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: IPP> Re: JMP> URGENT: Should impressions include blank In-Reply-To: Message-ID: <3.0.1.32.19980106173722.01024550@garfield> At 07:33 01/05/1998 PST, Caruso, Angelo wrote: >Tom, > >I disagree that the impressions counters are intended only for >monitoring. For monitoring, you only need the jobImpressionsCompleted >and jobImpressionsRequested counters. The fullColorImpressionsCompleted >and highlightColorImpressionsCompleted attributes were proposed >specifically for accounting with color capable devices. I was only talking about jobImpressionsCompleted, not fullColorImpressionsCompleted and highlightColorImpressionsCompleted. I agree with you that the latter two are useful for accounting as well as monitoring. > >Our assumption was that impressions would be more useful for accounting >since they are more accurate than sheets. Though I am not an accounting >expert, I think providing the impression counters gives an accounting >application developer added flexibility (e.g. so that billing for blank >sides could be made optional depending on the requirements of the >customer). That was always our thinking in doing the Job Monitoring MIB as well. That is why we made the impressions MANDATORY objects, and sheets as OPTIONAL attributes. It was only at the last minute that we discussed the issue of actually implementing impression counters in devices, that we came up with the idea that "impressions" are really counting sides that pass past the marker, whether marks are made or not (again, I'm not talking about color or high light multi-passes). > >I also agree with Bill Wagner that complete accuracy would require >measuring colorant use per side. We thought about this and decided it >was way too complicated for the job MIB. Our compromise solution was to >propose the fullColor and highlightColor impressions counters. > >At any rate, it is clear that we need more input from real customers on >their accounting requirements. For example, if most print shops charge >one per-sheet rate for color devices and another rate for monochrome >devices, then the color impressions counters aren't currently needed. >But providing them offers customers a competitive edge in their billing >methods since they can be more accurate. > >Thanks, >Angelo > > -----Original Message----- > From: Tom Hastings [SMTP:hastings@cp10.es.xerox.coM] > Sent: Thursday, December 18, 1997 10:21 PM > To: XCMI Editors only > Subject: RE: IPP> Re: JMP> URGENT: Should impressions >include blank last pageback sides or not? > > What about this proposal to recommend, but not require, that the > back side of the last sheet not count for impressions? > > Alternatively, we could make a note that impressions is intended > for monitoring, not accounting, and keep the definition of the >number > of passes past the marker, whether marks are made or not. > Sheets is intended for accounting > which in combination with the 'sides' attribute selects the >rate. > I believe this is what Kinkos does. > > Tom > > >X-Sender: spencerdr@vipmail.earthlink.net > >Date: Thu, 18 Dec 1997 10:03:04 PST > >To: "Wagner, William" > >From: David R Spencer > >Subject: RE: IPP> Re: JMP> URGENT: Should impressions include >blank last > > page back sides or not? > >Cc: ipp@pwg.org > >Sender: ipp-owner@pwg.org > >X-MIME-Autoconverted: from quoted-printable to 8bit by > garfield.cp10.es.xerox.com id LAA26719 > > > >Bill, > > > >I'm just monitoring the group, but isn't there a significant >difference > between blank pages within a document and documents in a duplex >job with an > odd number of pages causing the COMPLETELY blank back side of >the last page > to be counted? Almost all page printers include an option for >not printing > such completely blank pages, and I think the point about user >concern is > well taken. > > > >Therefore, perhaps the sentence in the definition of >impression: > >> If a two-sided document has an odd number of pages, the last >sheet still > counts as two impressions, if that sheet makes two passes >through the > marker or the marker marks on both sides of a sheet in a single >pass. > >should be: > >If a two-sided document has an odd number of pages and there >are no marks > to be made on second side of the last sheet, the last sheet >should count as > one impression, instead of two, even if that sheet makes two >passes through > the marker. > > > >David R. Spencer > > > >Spencer & Associates Publishing, Ltd. > >Three Giffard Way, Melville, NY 11747-2310 > >david@spencer.com > >1-516-367-6655 Fax:1-516-367-2878 > >http://www.spencer.com > >>______________________________________________________________________ > > > > > >>This was discussed in great detail at the LA meeting. If one >agrees > >>that the MIB is to provide information on what the printer >does, which > >>may not necessarily agree with what the rate structures may or >may not > >>be at a particular place at a particular time, then I think >the > >>contention that sending a sheet side through transfer and >fixing steps > >>constitutes making an impression. The question of how much >colorant is > >>put on that page is a separate one. If it is a single period, >a fully > >>colored page or a blank page, colorant use is a different >characteristic > >>from impression, and one which could be instrumented. > >> > >>In most page printers, the information that a page has no >marking is not > >>readily available. The page goes though the same processes, >takes pretty > >>much the same time and the same wear and tear on the >mechanism. I > >>suggest that, unless the printer has a way of separately >ejecting such > >>sheet sides, from a printer point of view, treating a blank >side > >>differently is an artificial distinction. > >> > >>The point may be moot. I am told that commercial duplication >houses > >>charge by the sheet, with perhaps a different sheet rate for >duplex (but > >>no distinction for blank sides). A large in-house reports >person told > >>me that there are no blank pages; there is a header or footer, >a page > >>number, or a "This page intentionally left blank" message. > >> > >>I suggest that a measure of importance from those actually >concerned > >>with the accounting be obtained before the MIB imposes the >derivation of > >>another parameter on the printer. > >> > >>W. A. Wagner (Bill Wagner) > >>OSICOM/DPI > >> > >>> -----Original Message----- > >>> From: Jay Martin [SMTP:jkm@underscore.com] > >>> Sent: Wednesday, December 17, 1997 11:50 PM > >>> To: Tom Hastings > >>> Cc: jmp@pwg.org; ipp@pwg.org > >>> Subject: IPP> Re: JMP> URGENT: Should impressions include >blank > >>> last page back sides or not? > >>> > >>> Sorry, but I must agree with Angelo Caruso with the position > >>> that most folks are going to be pretty upset if they are > >>> charged for blanks sides of sheets. Can't say that I like > >>> that idea at all. > >>> > >>> ...jay > >>> > >>> >---------------------------------------------------------------------- > >>> -- JK Martin | Email: jkm@underscore.com >-- > >>> -- Underscore, Inc. | Voice: (603) 889-7000 >-- > >>> -- 41C Sagamore Park Road | Fax: (603) 889-2699 >-- > >>> -- Hudson, NH 03051-4915 | Web: >http://www.underscore.com -- > >>> >---------------------------------------------------------------------- > > > > > > > > > > > > From hastings at cp10.es.xerox.com Thu Jan 8 15:23:48 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> MOD & JMP - Adding why to join ipp and jmp DLs Message-ID: <3.0.1.32.19980108122348.01039620@garfield> Both the IPP Model document and the JMP Job Monitoring MIB document list the email DL and how to join, using ipp-request@pwg.org and jmp-request@pwg.org. I'd like to see a sentence added as to why an implementor might want to join the DL. Implementors will find things that need clarification. Also both standards have registration processes for adding additional attributes and values. I've talked with Ron Bergman about this for the Job Monitoring MIB and he thought it was a good idea. How about adding the following sentence right after the mention of the ipp-request@pwg.org and jmp-request@pwg.org in the Author's addresses section: Implementors of this specification are encouraged to join this e-mail distribution list in order to partipate in any discussions of clarification issues and review of registration proposals for additional attributes and values. Comments? Thanks, Tom From rbergma at dpc.com Fri Jan 9 10:53:38 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> Editorial Correction; mediumConsumed attribute Message-ID: <3.0.1.32.19980108122348.01039620@garfield> Tom, Reference: Line 2508 in the pdf version of draft 07 reads- "OCTETS: MULTI-ROW: MULTI-ROW:" Does one of these "MULTI-ROW:" entries belong in line 2506? Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Fri Jan 9 13:35:44 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Editorial Correction; mediumConsumed attribute In-Reply-To: Message-ID: <3.0.1.32.19980109103544.00bb2e30@garfield> Yes. Thanks for cathing this. Tom At 07:53 01/09/1998 PST, Ron Bergman wrote: >Tom, > >Reference: Line 2508 in the pdf version of draft 07 reads- > > "OCTETS: MULTI-ROW: MULTI-ROW:" > >Does one of these "MULTI-ROW:" entries belong in line 2506? > > > Ron Bergman > Dataproducts Corp. > > > > From rbergma at dpc.com Mon Jan 12 16:38:28 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> Job Submission Protocol Mapping update Message-ID: <3.0.1.32.19980109103544.00bb2e30@garfield> Here is the text for the latest Job Submission Protocol mapping document for everyone to review. The text for NDPS has been added and is now only missing IPDS. (I was not able to format the document with the proper page breaks, so the table of contents may not be very useful.) Some additional changes were also made to the DPA section, see below. Tom, This version contains the NDPS changes per the discussions with Devon Taylor. As a result of these discussions I have changed the DPA mapping section 6.4 as follows: 1. Replacing jobHoldUntil with jobProcessAfterDateAndTime. 2. Deleting note 3 from the jobProcessAfterDataAndTime. 3. Renumbering all notes from 4 to 6. In reviewing the notes I do not believe that note 5 (was 6) is applicable. This note is mapping the DPA attribute to IPP. Also, as a result of the discussions, it seems that the NDPS sections and DPA sections should be very close. Could review the differences and determine if any further changes should be made to either protocol mapping? Ron Bergman Dataproducts Corp. INTERNET-DRAFT Ron Bergman Dataproducts Corp. January 12, 1998 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB Expires July 12, 1998 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet-Draft defines the recommended mapping for many currently popular Job submission protocols to objects and attributes the Job Monitoring MIB. TABLE OF CONTENTS 1.0 INTRODUCTION 3 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL 4 2.1 jmJobSubmissionId Mapped to LPR/LPD 4 2.2 jmJobIndex Mapped to LPR/LPD 5 2.3 Other MIB Objects Mapped to LPR/LPD 5 2.4 The Attribute Group Mapped to LPD 5 3.0 APPLETALK PROTOCOL 6 3.1 jmJobSubmissionId Mapped to AppleTalk 6 3.2 Other AppleTalk Mappings 6 4.0 INTERNET PRINTING PROTOCOL (IPP) 6 4.1 jmJobSubmissionId Mapped to IPP 7 4.2 jmJobIndex Mapped to IPP 7 4.3 Other MIB Objects Mapped to IPP 7 4.4 The Attribute Group Mapped to IPP 8 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) 8 6.0 DOCUMENT PRINTING APPLICATION (DPA) 8 6.1 jmJobSubmissionId Mapped to DPA 9 6.2 jmJobIndex Mapped to DPA 9 6.3 Other MIB Objects Mapped to DPA 9 6.4 The Attribute Group Mapped to DPA 10 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) 11 7.1 jmJobSubmissionId Mapped to NDPS 11 7.2 jmJobIndex Mapped to NDPS 11 7.3 Other MIB Objects Mapped to NDPS 11 7.4 The Attribute Group Mapped to NDPS 11 8.0 PRINTER JOB LANGUAGE (PJL) 13 8.1 jmJobSubmissionId Mapped to PJL 13 8.2 jmJobIndex Mapped to PJL 13 8.3 The Attribute Group Mapped to PJL 13 9.0 POSTSCRIPT 14 9.1 jmJobSubmissionId Mapped to PostScript 14 9.2 Other MIB Objects and Attributes Mapped to PostScript 14 10.0 NETWARE PSERVER 14 10.1 jmJobSubmissionId Mapped to PServer 14 10.2 jmJobIndex Mapped to PServer 15 10.3 The Attribute Group Mapped to PServer 15 11.0 NETWARE NPRINTER or RPRINTER 15 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL 16 12.1 jmJobSubmissionId Mapped to SMB 16 12.2 jmJobIndex Mapped to SMB 16 12.3 Other MIB objects Mapped to SMB 16 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) 17 13.1 jmJobSubmissionId Mapped to TIP/SI 17 13.2 jmJobIndex Mapped to TIP/SI 17 13.3 Other MIB Objects Mapped to TIP/SI 17 13.4 The Attribute Group Mapped to TIP/SI 17 14.0 REFERENCES 18 15.0 AUTHORS 18 1.0 INTRODUCTION The Job Monitoring MIB [JobMIB] is intended to be implemented in a device or server that supports any job submission protocol. However, the information available and the method of presentation varies significantly by job submission protocol. A common method of mapping job submission information to the Job Monitoring MIB is essential for interoperability of Job MIB agents and monitoring applications. This document defines recommended mappings for most popular job submission protocols to insure this compatibility. All mappings are unidirectional from the job submission protocol to the MIB. It is assumed that support of the job submission protocol in the printer implies that the reverse information flow is presently defined and does not require interaction from the MIB. This mapping is not defined in this document as it should be obvious. This document refers to system configurations that are defined in the Job Monitoring MIB [JobMIB]. For those readers that are familiar with the configuration descriptions, a short summary appears here. Please see the Job MIB document for further details. Configuration 1: This is a simple peer-to-peer system which contains only a client and a printer. The Job MIB agent is resident in the printer. Configuration 2: This system contains a client, server, and a printer. The Jib MIB agent is resident in the server. Configuration 3: This system, as in configuration 2, contains a client, server, and a printer. In this case the Job MIB agent is implemented within the printer. The most important object to be mapped is jmJobSubmissionId, since this is a method for the user or client to determine the jmJobIndex for a submitted job. Therefore, jmJobSubmissionId is specified for all job submission protocols defined in this document. The remaining objects mapped include only those items that have the equivalent information presented to the printer by the job submission protocol. While this document places a strong emphasis on jmJobSubmissionId mapping to obtain jmJobIndex, the preferred method is through the use of a bidirectional protocol that returns the value of jmJobIndex to the client, such as IPP. When a bidirectional protocol that returns jmJobIndex is in use, the jmJobSubmissionId object has no value to the client. When the jmJobIndex cannot be returned, the use of a client defined jmJobSubmissionId is preferred over an agent derived value. The client defined version allows for retrieval of jmJobIndex using a single SNMP Get operation, since jmJobSubmissionId is the index into the jmJobId table. An agent derived value will require a search through multiple entries in the jmJobId table. The majority of the protocols mapped in this document are oriented towards network job submission. However, the Job Monitoring MIB is also intended to monitor print jobs received from other than network ports, such as parallel and serial ports. Some of the job submission protocols included that are used with non-networked ports are PJL, PostScript, and TIP/SI. In addition, the Job Monitoring MIB can be used with print jobs that are internally generated, such as self test pages. In this latter case, no mapping is required since all job submission protocols are bypassed. 2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL The LPR/LPD printing protocol [LPD] is used with BSD Unix systems in the client-server-printer configuration. Usage of the Job Monitoring MIB with LPR/LPD will most likely conform to Configuration 3, where the monitor application or the server uses SNMP to obtain job information from the printer. The client communicates with the Unix server using the existing LPD protocol to obtain job information. The LPR/LPD protocol is also used in the Windows environment to implement peer-to-peer printing, as shown in configuration 1. In this case, SNMP is used by the client and/or the monitor application to obtain the job information. One of the major problems of LPR/LPD is the large number of vendor unique extensions currently used with the protocol and the resulting compatibility issues between available implementations. To avoid these issues, this mapping of LPR/LPD is restricted to the protocol as defined by RFC 1179. The LPR/LPD protocol transfers print job data and control information in separate files, known as the Data File and Control File, respectively. Most of the information concerning the print job is contained in the Control File. In many LPD implementations, the Control File is transferred following the Data File. Thus much of the information concerning the job may not be available until the completion of the data transmission. 2.1 jmJobSubmissionId Mapped to LPR/LPD The LPR/LPD Receive Data File command contains a parameter which defines the name of the data file. This name field is structured as follows: dfaXXX or daXXXX Where XXX or XXXX is the numeric job number assigned by the LPR/LPD client submitting the print job. The recommended mapping of this name field to jmJobSubmissionId is: octet 1: '9' octets 2-40: Contains the portion of the name field. If the portion is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: '00000XXX' or '0000XXXX', where XXX or XXXX is the decimal (ASCII coded) representation of the LPR/LPD job number. 2.2 jmJobIndex Mapped to LPR/LPD The job index (jmJobIndex) is assigned by the SNMP job monitoring agent and is independent of the XXX (or XXXX) index assigned by the LPR/LPD client. This will allow the SNMP agent to track jobs received from multiple sources. 2.3 Other MIB Objects Mapped to LPR/LPD MIB Object | LPR/LPD Parameter -----------------------+------------------------------------------------ jmJobKOctetsRequested | Number of bytes as defined in the Data File jmJobOwner | Control file command code = P (User Id) 2.4 The Attribute Group Mapped to LPD Other attributes that are applicable, but not defined in this section such as attributes that map to a vendor unique extension, may also be included. MIB attribute | LPR/LPD information | Data type ----------------------+---------------------------------+-------------- jobName | Name of the data file (note 1) | Octet String queueNameRequested | Queue name from the Data File | Octet String fileName | Source File Name (notes 2, 3) | Octet String documentName | Document title (notes 2, 4) | Octet String Notes: ------ 1. See section 2.1 (jmJobSubmissionId). 2. The information is optional in the Control File. The attribute should be included if present in the Control File. 3. Control file command code = N. 4. Control file command code = J. 3.0 APPLETALK PROTOCOL AppleTalk was originally developed as a peer-to-peer network protocol, as described in configuration 1, for use with Apple Macintosh computers. Today, print spoolers are also available for use with Macintosh computer networks that conform to configurations 2/3. In addition, printing with the AppleTalk protocol is supported from both Windows NT servers and Novell servers also per configurations 2/3. The AppleTalk protocol provides very little information that can be used with the Job Monitoring MIB. The Macintosh print drivers are able to provide information concerning the user and document name but imbed this information in the PDL, which is typically PostScript. The preferred jmJobSubmissionId is constructed from the information in the PostScript file, as defined in section 9.0. 3.1 jmJobSubmissionId Mapped to AppleTalk An alternative jmJobSubmissionId may be constructed from the Connection Identifier contained in the AppleTalk Printer Access Protocol (PAP) header. Since the Connection Id is not readily available in any of the defined AppleTalk implementations, this approach may be of little utility. octet 1: 'A' octets 2-40: Contains the AppleTalk printer name, with the first character of the name in octet 2. AppleTalk printer names are a maximum of 31 characters. Any unused portion of this field shall be filled with spaces. octets 41-48: '00000XXX', where 'XXX' is the decimal (ASCII coded) representation of the Connection Id. 3.2 Other AppleTalk Mappings No other Job MIB objects or parameters can be derived from information available in the AppleTalk headers 4.0 INTERNET PRINTING PROTOCOL (IPP) The Internet Printing Protocol [IPP] supports printing using any one of the three possible configurations. For configuration 2, the mapping defined herein is performed on an agent within the server. Otherwise, the mapping is performed on an agent within the printer. 4.1 jmJobSubmissionId Mapped to IPP IPP contains a rich set of parameters which allow several methods of creating the jmJobSubmissionId object. To prevent interoperability problems, the preferred method is to use the IPP job-uri attribute as follows: octet 1: '4' octets 2-40: Contains the IPP job-uri job description attribute generated by the printer. (The job-uri is returned to the client by IPP.) If the job-uri is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: Contains the decimal (ASCII coded) representation of the job-id job template attribute. Leading zeros shall be inserted to fill the entire 8 octet field. 4.2 jmJobIndex Mapped to IPP The job index (jmJobIndex) assigned by the SNMP job monitoring agent is returned to the client by IPP as the job-id job description attribute. (Since IPP does not require consecutively generated job-ids, the agent may receive jobs from multiple clients and can assign jmJobIndex in an ascending sequence independent of the submitting job client.) The IPP job-id must be restricted to the range of 1 to 99,999,999 (decimal) to allow the value to be properly represented in jmJobSubmissionId. 4.3 Other MIB Objects Mapped to IPP MIB Object | IPP Job attribute --------------------------+--------------------------------------------- jmJobOwner | job-originating-user jmJobKOctetsRequested | job-k-octets jmJobKOctetsProcessed | job-k-octets-processed jmJobImpressionsRequested | job-impressions jmJobImpressionsProcessed | job-impressions-completed jmJobStateReasons1 | job-state-reasons (note 1) jmNumberOfInterveningJobs | number-of-intervening-jobs Notes: ------ 1. JobStateReasons is a bit map described in one object and three attributes. The IPP condition may change one or more of the bits in one or more of these Job MIB items. 4.4 The Attribute Group Mapped to IPP The following mappings are required if the listed IPP job template attribute is provided. MIB attribute | IPP job attribute | Data type ---------------------------+------------------------------+------------- jobCodedCharSet | attributes-charset (note 1) | Octet String jobNaturalLanguage | attributes-natural-language | Octet String jobName | job-name | Octet String documentFormat | document-format | Octet String jobPriority | job-priority | Integer jobHoldUntil | job-hold-until | Octet String sides | sides (note 2) | Integer finishing | finishings | Integer printQualityRequested | print-quality | Integer printerResolutionRequested | printer-resolution | Integer jobCopiesRequested | copies | Integer mediumRequested | media | Octet String jobSubmissionTime | time-at-submission | Integer jobStartedProcessingTime | time-at-processing | Integer jobCompletionTime | time-at-completed | Integer sheetsRequested | job-media-sheets | Integer jobURI | job-uri | Octet String jobStateReasonsN | job-state-reasons (note 3) | Integer physicalDevice | output-device-assigned | Octet String sheetsCompleted | job-media-sheets-completed | Integer Notes: ------ 1. jobCodedCharSet is an enum from the IANA registry which is also used in the Printer MIB. The IPP attributes-charset is the name (MIME preferred) of the character set. 2. The Job MIB sides attribute uses the integer values "1" and "2". The IPP sides attribute uses three keywords. 3. jobStateReasons is a bit map described in one object and three attributes. The IPP condition may change one or more of the bits in one or more of these Job MIB items. 5.0 INTELLIGENT PRINTER DATA STREAM (IPDS) 6.0 DOCUMENT PRINTING APPLICATION (DPA) The ISO 10175 Document Printing Application [DPA] supports printing using any one of the three possible configurations. For configuration 2, the mapping defined herein is performed on a server. Otherwise, the mapping is performed on an agent within the printer. 6.1 jmJobSubmissionId Mapped to DPA DPA contains a rich set of parameters which allow several methods of creating the jmJobSubmissionId object. To prevent interoperability problems, the preferred method is to use the DPA job-originating-user attribute as follows: octet 1: '0' octets 2-40: Contains the DPA job-owner attribute supplied by the submitter. If the job-owner is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: Contains an 8-digit sequential decimal number. 6.2 jmJobIndex Mapped to DPA The job index (jmJobIndex) assigned by the SNMP job monitoring agent is returned to the client by DPA as a decimal digit string as the value of the DPA job-identifer attribute. (Since DPA does not require consecutively generated job-identifiers, the agent may receive jobs from multiple clients and can assign the jmJobIndex in an accending sequence independent of the submitting job client.) The DPA job-identifier must be restricted to the range of 1 to 99,999,999 (decimal) to allow the value to be properly represented in jmJobSubmissionId. 6.3 Other MIB Objects Mapped to DPA MIB Object | DPA Job attribute --------------------------+--------------------------------------------- jmJobOwner | job-owner jmJobKOctetsRequested | total-job-octets (note 1) jmJobKOctetsProcessed | job-octets-completed (note 1) jmJobImpressionsRequested | job-impression-count jmJobImpressionsProcessed | impressions-completed jmJobStateReasons1 | job-state-reasons (note 2) jmNumberOfInterveningJobs | intervening-jobs Notes: ------ 1. jmJobKOctetsRequested and jmJobKOctetsProcessed is in K octets while the DPA job-total-octets and job-octets-completed is in octets and is 63-bits of significance. 2. JobStateReasons is a bit map described in one object and three attributes. The DPA condition may change one or more of the bits in one or more of these Job MIB items. Also the DPA job-state-reasons is a multi-valued attribute with each value being an OBJECT IDENTIFIER (OID). 6.4 The Attribute Group Mapped to DPA The following mappings are required if the listed DPA job attribute is provided. MIB attribute | DPA job attribute |IPP Data type ---------------------------+------------------------------+------------- jobCodedCharSet | (note 1) | Octet String jobNaturalLanguage | document-natural-language | Octet String jobName | job-name | Octet String documentFormat | document-format | Octet String jobPriority | job-priority | Integer jobProcessAfterDateAndTime | job-print-after | Octet String sides | sides (note 3) | Integer finishing | job-finishing, finishing | Integer printQualityRequested | print-quality | Integer printerResolutionRequested | default-printer-resolution | Integer | (note 4) | jobCopiesRequested | job-copies-requested | Integer mediumRequested | page-media-select, | Octet String | default-medium | jobSubmissionTime | submission-time (note 5) | Integer jobStartedProcessingTime | started-printing-time (note 5) Integer jobCompletionTime | completion-time (note 5) | Integer sheetsRequested | job-media-sheet-count | Integer jobURI | job-uri | Octet String jobStateReasonsN | job-state-reasons (note 2) | Integer physicalDevice | printers-assigned | Octet String sheetsCompleted | job-media-sheets-completed | Integer Notes: ------ 1. Every DPA attribute is tagged indicating the coded character set to be used for that attribute. 2. JobStateReasons is a bit map described in one object and three attributes. The DPA condition may change one or more of the bits in one or more of these Job MIB items. Also the DPA job-state-reasons is a multi-valued attribute with each value being an OBJECT IDENTIFIER (OID). 3. The Job MIB sides attribute is an integer '1' or '2' while the DPA sides attribute has one of six OID values that includes plex. 4. printerResolutionRequested has x and y resolution and is intended to override the resolution instruction in the document, if any, while the DPA default-printer-resolution is the same in x and y and only takes effect if the document does not contain a resolution instruction 5. IPP times are the number of seconds since boot time, while DPA times are a date/time. 7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) Novell Distributed Print Services is a DPA based job submission protocol that conforms to configuration 3. 7.1 jmJobSubmissionId Mapped to NDPS NDPS supports the generation of a properly formatted jmJobSubmissionId for use in the Job MIB, via the attribute ndps-att-job-identifier. ISSUE: Is this the proper NDPS atrribute or should the attrribute ndps- att-identifier-on-client or ndps-att-new-job-identifier to be used? 7.2 jmJobIndex Mapped to NDPS NDPS defines the attribute ndps-att-job-identifier-on-printer that can be used to return the value of jmJobIndex to the NDPS client. 7.3 Other MIB Objects Mapped to NDPS MIB Object | NDPS Parameter ---------------------------------+-------------------------------------- jmJobOwner | ndps-att-job-owner jmJobState | ndps-att-current-job-state (note 1) jmJobStateReasons1 | ndps-att-job-state-reasons (note 2) jmJobKOctetsProcessed | ndps-att-octets-completed jmJobImpressionsCompleted | ndps-att-impressions-completed jmNumberOfInterveningJobs | ndps-att-intervening-jobs jmJobImpressionsPerCopyRequested | ndps-att-job-impressions-count | (note 3) Notes: ------ 1. Some of the NDPS job states must be represented by both a jmJobState and a jmJobStateReasons1 object or a jobStateReasonsN attribute. 2. The NDPS job state reasons may be mapped to either the object jmJobStateReasons1 or the attribute jobStateReasonsN. 3. The Job MIB object must be multiplied by the attribute jobCopiesRequested to obtain the NDPS attribute value, if multiple copies have been requested. 7.4 The Attribute Group Mapped to NDPS The following mappings are required if the listed PJL attribute or command option is provided. MIB attribute | NDPS parameter | Data type ---------------------------+------------------------------+------------- jobAccountName | ndps-att-job-owner | Octet String jobName | ndps-att-job-name | Octet String numberOfDocuments | ndps-att-number-of-documents | Integer fileName | ndps-att-document-file-name | Octet String documentName | ndps-att-document-name | Octet String jobComment | ndps-att-job-comment | Octet String documentFormatIndex | ndps-att-prtInterpreterIndex | Integer documentFormat | ndps-att-document-format | Integer jobPriority | ndps-att-job-priority | Integer jobProcessAfterDateAndTime | ndps-att-job-print-after | Octet String outputBin | ndps-att-results-profile | Integer | (note 1) | sides | ndps-att-sides (note 2) | Integer finishing | ndps-att-job-finishing | Integer printQualityRequested | ndps-att-print-quality | Integer printerResolutionRequested | ndps-att-default-printer-- | | resolution (note 3) | Integer printerResolutionUsed | ndps-att-default-resolutions-- | used | Integer jobCopiesRequested | ndps-att-results-profile | Integer | (note 4) | mediumConsumed | ndps-att-media-used | Integer jobSubmissionToServerTime | ndps-att-submission-time | Octet String jobSubmissionTime | ndps-att-started-printing-time Octet String jobOriginatingHost | ndps-att-job-originator | Octet String numberOfDocuments | ndps-att-number-of-documents | Integer jobCompletionTime | ndps-att-completion-time | Octet String jobCopiesCompleted | ndps-att-job-copies-completed| Integer sheetsRequested | ndps-att-job-media-- | | sheet-count | Integer sheetsCompleted | ndps-att-media-sheets-- | | completed | Integer documentCopiesRequested | ndps-att-copy-count | Integer documentCopiesCompleted | ndps-att-copies-completed | Integer | (note 3) Notes: ------ 1. The output-bin field in ndps-att-results-profile is to be used. 2. The Job MIB sides attribute is an integer '1' or '2' while the NDPS sides attribute has one of six OID values that includes plex. 3. printerResolutionRequested has x and y resolution and is intended to override the resolution instruction in the document, if any, while the ndps-att-default-printer-resolution is the same in x and y and only takes effect if the document does not contain a resolution instruction 4. The job-copies field in ndps-att-results-profile is to be used. 8.0 PRINTER JOB LANGUAGE (PJL) PJL [PJL] has been developed by Hewlett-Packard to provide job control information to the printer and status information to applications, independent of the PDL. 8.1 jmJobSubmissionId Mapped to PJL PJL has defined the SUBMISSIONID option for the JOB command which indicates a properly formatted jmJobSubmissionId for use in the Job MIB. The PJL JOB command is presented at the start of a print job with options that apply only the attached job. The syntax for this command option is: @PJL JOB SUBMISSIONID = "id string" Driver software that implements this PJL command option must provide the "id string" in one of the client version formats specified in the Job MIB for jmJobSubmissionId. For drivers that are not able to create the SUBMISSIONID option, it is recommended that jmJobSubmissionId format 0 be created by the agent using the PJL attribute DocOwner or DocOwnerId. octet 1: '0' octets 2-40: Contains the string associated with DocOwner or DocOwnerId. If the string is less than 40 octets, the left-most character in the string shall appear in octet position 2. Otherwise, only the last 39 bytes shall be included. Any unused portion of this field shall be filled with spaces. If DocOwner or DocOwnerId cannot be obtained, this field shall be blank. octets 41-48: Contains the value of jmJobIndex associated with the job. Leading zeros shall be inserted to fill the entire 8 octet field. 8.2 jmJobIndex Mapped to PJL PJL does not provide a value that can be mapped to jmJobIndex. 8.3 The Attribute Group Mapped to PJL The following mappings are required if the listed PJL attribute or command option is provided. MIB attribute | PJL attribute or command option | Data type ----------------------+----------------------------------+-------------- jobOwner | DocOwner or DocOwnerId attribute | Octet String serverAssignedJobName | DocName attribute or the command | Octet String | @PJL JOB Name = "string" | Octet String submittingServerName | SrcServerName attribute | Octet String jobOriginatingHost | SrcPort attribute | Octet String queueNameRequested | SrcQ attribute | Octet String fileName | JobFName attribute | Octet String jobComment | JobDesc attribute | Octet String jobSubmissionTime | TimeSubmit attribute | Octet String 9.0 POSTSCRIPT The PostScript PDL permits comment fields which can be used by application drivers to include job information. Although there are no restrictions or requirements as to what information may be included, many drivers include job owner and/or document name. 9.1 jmJobSubmissionId Mapped to PostScript The use of a standard format job submission id comment string will allow interoperability of printers and drivers from multiple vendors. The following comment string format is recommended for use with PostScript level 1 and level 2 data streams. %%JMPJobSubmissionId:(id-string) where "id string" can be any jmJobSubmissionId format reserved for clients. 9.2 Other MIB Objects and Attributes Mapped to PostScript No Other mappings from PostScript comment strings are recommended, but many Job MIB objects and attributes can be defined using vendor unique comment strings. 10.0 NETWARE PSERVER The NetWare PServer job submission protocol is implemented in a client- server-printer system on the server to printer link as defined in configuration 3. 10.1 jmJobSubmissionId Mapped to PServer octet 1: 'B' octets 2-40: Contains the Directory Path Name of the agent as recorded by the Novell File Server in the queue directory. If the string is less than 40 octets, the left-most character in the string shall appear in octet position 2. Otherwise, only the last 39 bytes shall be included. Any unused portion of this field shall be filled with spaces. octets 41-48: '000XXXXX' The decimal (ASCII coded) representation of the Job Number as per the NetWare File Server Queue Management Services. 10.2 jmJobIndex Mapped to PServer The job index (jmJobIndex) is assigned by the SNMP job monitoring agent and is independent of the Job Number assigned by the NetWare File Server Queue Management Services. This will allow the SNMP agent to track jobs received from multiple sources. 10.3 The Attribute Group Mapped to PServer The following mappings are required if the listed PServer parameter is provided in the Novell File Server queue directory. MIB attribute | PServer parameter | Data type ---------------------------+-----------------------------+-------------- jobOwner | Client Id Number | Integer serverAssignedJobName | Job File Name | Octet String queueNameRequested | Queue Id | Integer physicalDevice | Server Id Number | Integer jobComment | Job Description | Octet String jobPriority | (note 1) | Integer jobProcessAfterDateAndTime | Target Execution Time | Octet String jobCopiesRequested | Number of Copies | Integer mediumRequested | Form Name | Octet String jobSubmittedToServerTime | Job Entry Time | Octet String Notes: ------ 1. The job priority is determined by the priority assigned to the queue that contains the job. Each queue can be assigned a unique priority and the priority of the job is inherited from the queue. 11.0 NETWARE NPRINTER or RPRINTER The NetWare NPrinter/RPrinter protocol was designed to transfer print data from a Novell File Server to a printer attached directly to a local port (e.g. parallel or serial) on a PC. NPrinter/RPrinter is an extremely lightweight printing protocol. Consequently, no information required by the Job Monitoring MIB is provided and a meaningful jmJobSubmissionId cannot be generated. It is recommended that an additional job submission layer, such as PJL or another vendor private protocol, be included on top of NPrinter/RPrinter to provide the required information. The mapping should then be performed according to the recommendations of the higher layer submission protocol. 12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL The Server Message Block protocol is used with several PC Network operating systems, such as Microsoft Windows for Workgroups, IBM LAN Server, and Artisoft Lantastic. SMB systems supporting the Job Monitoring MIB will conform to either configuration 1 or 3. 12.1 jmJobSubmissionId Mapped to SMB octet 1: 'C' octets 2-40: Contains a decimal (ASCII coded) representation of the 16 bit SMB Tree Id field, which uniquely identifies the connection that submitted the job to the printer. The most significant digit of the numeric string shall be placed in octet position 2. All unused portions of this field shall be filled with spaces. The SMB Tree Id has a maximum value of 65,535. octets 41-48: Contains a decimal (ASCII coded) representation of the File Handle returned from the printer agent to the client in response to a Create Print File command. Leading zeros shall be inserted to fill the entire 8 octet field. 12.2 jmJobIndex Mapped to SMB It is strongly recommended that the File Handle returned from the printer agent be identical to jmJobIndex. If these items are identical, there is no need for the client application to perform a search on jmJobSubmissionId. To be compatible with the 16 bit field allocated to this value by SMB, the maximum jmJobIndex is 65,535. 12.3 Other MIB objects Mapped to SMB MIB Object | SMB Parameter ----------------+------------------------------------------------ jmJobOwner | SMB User Id field (note 1) Notes: ------ 1. A decimal (ASCII coded) representation of the SMB User Id numeric shall be presented as jmJobOwner. 13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) The TIP/SI protocol, although currently specified as a part of the IEEE 1284 parallel port standards [TIP/SI], was originally developed as a network protocol. TIP/SI thus has the potential of being integrated into any network or non-network configuration. 13.1 jmJobSubmissionId Mapped to TIP/SI octet 1: 'D' octets 2-40: Contains the Job Name from the Job Control-Start Job (JC-SJ) command. If the Job Name portion is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: Contains a decimal (ASCII coded) representation of the jmJobIndex assigned by the agent. Leading zeros shall be inserted to fill the entire 8 octet field. 13.2 jmJobIndex Mapped to TIP/SI jmJobIndex is returned to the client as the Printer Assigned Job Id in a Job Control-Start Job (JC-SJ) response packet. To be compatible with the 16 bit field allocated to this value by TIP/SI, the maximum jmJobIndex is 65,535. 13.3 Other MIB Objects Mapped to TIP/SI MIB Object | TIP/SI Parameter -----------------------+------------------------------------------------ jmJobOwner | User string 13.4 The Attribute Group Mapped to TIP/SI MIB attribute | TIP/SI information | Data type ----------------------+---------------------------------+-------------- jobName | Job Name string | Octet String jobComment | Additional Information string | Octet String 14.0 REFERENCES [IPP] The Internet Printing Protocol RFC XXXX, Model RFC XXXX [JobMIB] The Job Monitoring MIB, RFC XXXX, IETF informational document. [LPD] Line Printer Daemon Protocol, RFC 1179, IETF informational document. [PJL] Printer Job Language Technical Reference Manual, Hewlett-Packard part number 5021-0328. [PrtMIB] The Printer MIB, RFC 1759, IETF standards track document. [TIP/SI] IEEE Standard 1284.1, Transport Independent Printer/System Interface. 15.0 AUTHORS This document was created with significant contributions from the following individuals. Ron Bergman (Editor) Dataproducts Corp. 1757 Tapo Canyon Road Simi Valley, CA 93063-3394 Phone: 805-578-4421 Fax: 805-578-4001 Email: rbergman@dpc.com Tom Hastings Xerox Corporation, ESAE-231 701 S. Aviation Blvd. El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com 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 Harry Lewis IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301 Phone: (303) 924-5337 Fax: (303) 924-4662 Email: harryl@us.ibm.com Bob Pentecost Hewlett-Packard Corporation 11311 Chinden Boulevard Boise, ID 83714 Phone: (208) 396-3312 Fax: (208) 396-4122 Email: bpenteco@boi.hp.com Send comments to the printmib WG using the Job Monitoring Project (JMP) Mailing List: jmp@pwg.org For further information, access the PWG web page under "JMP": http://www.pwg.org/ Other Participants: Chuck Adams - Tektronix Keith Carter - IBM Corporation Angelo Caruso - Xerox Jeff Copeland - QMS Andy Davidson - Tektronix Mabry Dozier - QMS Lee Ferrel - Canon David Kellerman - Northlake Software Rick Landau - Digital Jay Martin - Underscore Ira McDonald - Xerox Stuart Rowley - Kyocera Bob Setterbo - Adobe Gail Songer - EFI Mike Timperman - Lexmark William Wagner - DPI/Osicom Chris Wellens - Interworking Labs Rob Whittle - Novell Don Wright - Lexmark Lloyd Young - Lexmark Job Submission Protocol Mapping Recommendations Jan 12, 1998 Bergman [page 8] Bergman [page 1] From rbergma at dpc.com Wed Jan 14 11:49:46 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG OID Structure Proposals Message-ID: <3.0.1.32.19980109103544.00bb2e30@garfield> There was considerable email discussion last December regarding the structure of the OIDs in the PWG enterprises subtree, without a final resolution. Here is a summary of the proposed PWG OID structures: 1. A flat structure where each item, whether it is a MIB, operations, attributes, etc, is assigned a number under 2699. For example: ....2699.1 = Job Monitoring MIB ....2699.2 = Finisher MIB ....2699.3 = Printer MIB-2 ....2699.4 = IPP operations ....2699.5 = IPP Attributes ....2699.6 = Finisher MIB extensions ....2699.7 = Job Monitoring MIB extensions The next number in sequence is assigned as needed. Experimental OIDs could be indicated by numbers in a higher range. For example, numbers of 10000 or greater would be experimental. Or, until a document is released as official, either as a IETF RFC or by some other approved means, it is still regarded as experimental. In this latter case, some numbers may never become approved. 2. A project structure where related items are grouped together. In this case the above would be grouped: ....2699.1 = Job Monitoring ....2699.1.1 = Job Monitoring MIB ....2699.1.2 = Job Monitoring MIB extensions ....2699.2 = Finisher ....2699.2.1 = Finisher MIB ....2699.2.2 = Finisher MIB extensions ....2699.3 = Printer ....2699.3.1 = Printer MIB-2 ....2699.4 = IPP ....2699.4.1 = IPP operations ....2699.4.2 = IPP Attributes 3. A function structure where items are grouped by document type. Again, the above items would now be grouped: ....2699.1 = MIBs ....2699.1.1 = Job Monitoring MIB ....2699.1.2 = Finisher MIB ....2699.1.3 = Printer MIB-2 ....2699.1.4 = Finisher MIB extensions ....2699.1.5 = Job Monitoring MIB extensions ....2699.2 = Protocols ....2699.2.1 = IPP ....2699.2.1.1 = IPP operations ....2699.2.1.2 = IPP Attributes 4. A major grouping by experimental and standard items. ....2699.1 = PWG Standard OIDs ....2699.2 = PWG Experimental OIDs Combinations of the above are also possible. For example, the experimental / standard grouping could be followed by the function structure and followed by the project structure. (It is an exercise for the reader to create this figure using the above items.) This subject was also discussed in the JMP session at both the Boulder and LA meetings. In the Boulder meeting, Harry proposed the project structure and I proposed the flat structure. In both meetings there was not much excitement for this topic and the general agreement was the flat structure was good enough. The current Job Monitoring MIB follows the project structure and results in the following OIDs: First MIB object jmGeneralJobSetIndex: (x = Table index) 1.3.6.1.4.1.2699.1.1.1.1.1.1.1.x (15 OID positions) Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) 1.3.6.1.4.1.2699.1.1.1.4.1.1.4.x.y.z (17 OID positions) Using the combinations of structures 2, 3, and 4 these OIDs are: First MIB object jmGeneralJobSetIndex: (x = Table index) 1.3.6.1.4.1.2699.1.1.1.1.1.1.1.1.1.x (17 OID positions) Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) 1.3.6.1.4.1.2699.1.1.1.1.1.4.1.1.4.x.y.z (19 OID positions) Using the flat structure provides the shortest OIDs: First MIB object jmGeneralJobSetIndex: (x = Table index) 1.3.6.1.4.1.2699.1.1.1.1.1.1.x (14 OID positions) Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) 1.3.6.1.4.1.2699.1.1.4.1.1.4.x.y.z (16 OID positions) While I believe that the combination of all three structures provides the most information and flexibility, do we really need all this capability? There is usually some elegance in simplicity. How many projects will require an OID assignment in the future? As should be evident, my preference is for the flat model. But I do not see a major implementation difference in any of the proposals. We do need to reach a group consensus on this topic to complete the Job MIB. This issue should be discussed and an agreement reached in Maui. I would like to add this discussion to the PWG general topics on Wednesday morning. Ron Bergman Dataproducts Corp. From b_nixon at emulex.com Wed Jan 14 12:47:00 1998 From: b_nixon at emulex.com (Nixon, Bob) Date: Wed May 6 14:00:13 2009 Subject: JMP> RE: PWG> PWG OID Structure Proposals Message-ID: <199801141750.AA15362@emulex.emulex.com> I'm not educated enough to have an opinion on the PWG MIB structure, but here is a point to consider... Feedback from our customers has often indicated that "MIB walk" (sequential access in OID order) needs to present a usable view of a system and / or its subsystems. This would argue against a "flat" or "functional" organization because a large body of unrelated information may lie (in the examples, does lie) sequentially between the MIB for a project ("subsystem"?) and its later-developed extensions. The "project" organization seems better able to support this goal. - Bob Nixon. Emulex Network Systems ---------- From: Ron Bergman[SMTP:rbergma@dpc.com] Sent: Wednesday, January 14, 1998 8:49 AM To: jmp; pwg Subject: PWG> PWG OID Structure Proposals ---------------------------------------------------- There was considerable email discussion last December regarding the structure of the OIDs in the PWG enterprises subtree, without a final resolution. Here is a summary of the proposed PWG OID structures: 1. A flat structure where each item, whether it is a MIB, operations, attributes, etc, is assigned a number under 2699. For example: From don at lexmark.com Wed Jan 14 17:14:49 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG Meeting Agenda - Final Message-ID: <199801150126.AA09514@interlock2.lexmark.com> Here's the final meeting agenda for Jan 26-30. Details on the individual groups will be provided by the appropriate chairs. Status presentations and subsequent discussion will be STRICTLY limited to 10 minutes. If a chair is not going to be present, please post your status to the mailing list and send it to me at least 1 week before the meeting. Monday, Jan 26 8:30 - 5:30 1394 Printing Tuesday, Jan 27 8:30 - 5:30 1394 Printing Wednesday, Jan 28 8:30 PWG General Meeting 8:30 Next Meetings 8:45 Print MIB Status 8:55 Job MIB Status 9:05 Finisher MIB Status 9:15 Sense Status 9:25 IPP Status 9:35 1394 Printing Status 9:45 Open PWG Issues - Job MIB traps - others 10:30 IPP - XML - other open issues Thursday, Jan 29 8:30 - 5:30 IPP - overflow from Wednesday - Prototyping Friday, Jan 30 8:30 - 5:30 Finisher MIB ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From don at lexmark.com Wed Jan 14 20:55:59 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG OID Structure Proposals In-Reply-To: PWG OID Structure Proposals> Message-ID: <199801150202.AA10328@interlock2.lexmark.com> What about a combination of the functional and project structure that reserves spaces for future projects related to existing projects? For example: ....2699.1 = MIBs ....2699.1.1 = Job Monitoring ....2699.1.1.1 = Job MIB ....2699.1.1.2 = Job MIB extensions #1 ....2699.1.1.3 = Job MIB extensions #2 ....2699.1.2 = Finisher ....2699.1.2.1 = Finisher MIB ....2699.1.2.2 = Finisher MIB extensions ....2699.1.3 = Printer ....2699.1.3.1 = Printer MIB II ....2699.1.3.2 = Printer MIB II extensions ....2699.2 = Protocols ....2699.2.1 = IPP ....2699.2.1.1 = IPP operations ....2699.2.1.2 = IPP Attributes I think this has the advantages of both. The only downside is that the structure is one digit longer than either --- not really much of a problem. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** rbergma%dpc.com@interlock.lexmark.com 01/14/98 11:49 AM To: jmp%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: JMP> PWG OID Structure Proposals There was considerable email discussion last December regarding the structure of the OIDs in the PWG enterprises subtree, without a final resolution. Here is a summary of the proposed PWG OID structures: 1. A flat structure where each item, whether it is a MIB, operations, attributes, etc, is assigned a number under 2699. For example: ....2699.1 = Job Monitoring MIB ....2699.2 = Finisher MIB ....2699.3 = Printer MIB-2 ....2699.4 = IPP operations ....2699.5 = IPP Attributes ....2699.6 = Finisher MIB extensions ....2699.7 = Job Monitoring MIB extensions The next number in sequence is assigned as needed. Experimental OIDs could be indicated by numbers in a higher range. For example, numbers of 10000 or greater would be experimental. Or, until a document is released as official, either as a IETF RFC or by some other approved means, it is still regarded as experimental. In this latter case, some numbers may never become approved. 2. A project structure where related items are grouped together. In this case the above would be grouped: ....2699.1 = Job Monitoring ....2699.1.1 = Job Monitoring MIB ....2699.1.2 = Job Monitoring MIB extensions ....2699.2 = Finisher ....2699.2.1 = Finisher MIB ....2699.2.2 = Finisher MIB extensions ....2699.3 = Printer ....2699.3.1 = Printer MIB-2 ....2699.4 = IPP ....2699.4.1 = IPP operations ....2699.4.2 = IPP Attributes 3. A function structure where items are grouped by document type. Again, the above items would now be grouped: ....2699.1 = MIBs ....2699.1.1 = Job Monitoring MIB ....2699.1.2 = Finisher MIB ....2699.1.3 = Printer MIB-2 ....2699.1.4 = Finisher MIB extensions ....2699.1.5 = Job Monitoring MIB extensions ....2699.2 = Protocols ....2699.2.1 = IPP ....2699.2.1.1 = IPP operations ....2699.2.1.2 = IPP Attributes 4. A major grouping by experimental and standard items. ....2699.1 = PWG Standard OIDs ....2699.2 = PWG Experimental OIDs Combinations of the above are also possible. For example, the experimental / standard grouping could be followed by the function structure and followed by the project structure. (It is an exercise for the reader to create this figure using the above items.) This subject was also discussed in the JMP session at both the Boulder and LA meetings. In the Boulder meeting, Harry proposed the project structure and I proposed the flat structure. In both meetings there was not much excitement for this topic and the general agreement was the flat structure was good enough. The current Job Monitoring MIB follows the project structure and results in the following OIDs: First MIB object jmGeneralJobSetIndex: (x = Table index) 1.3.6.1.4.1.2699.1.1.1.1.1.1.1.x (15 OID positions) Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) 1.3.6.1.4.1.2699.1.1.1.4.1.1.4.x.y.z (17 OID positions) Using the combinations of structures 2, 3, and 4 these OIDs are: First MIB object jmGeneralJobSetIndex: (x = Table index) 1.3.6.1.4.1.2699.1.1.1.1.1.1.1.1.1.x (17 OID positions) Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) 1.3.6.1.4.1.2699.1.1.1.1.1.4.1.1.4.x.y.z (19 OID positions) Using the flat structure provides the shortest OIDs: First MIB object jmGeneralJobSetIndex: (x = Table index) 1.3.6.1.4.1.2699.1.1.1.1.1.1.x (14 OID positions) Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) 1.3.6.1.4.1.2699.1.1.4.1.1.4.x.y.z (16 OID positions) While I believe that the combination of all three structures provides the most information and flexibility, do we really need all this capability? There is usually some elegance in simplicity. How many projects will require an OID assignment in the future? As should be evident, my preference is for the flat model. But I do not see a major implementation difference in any of the proposals. We do need to reach a group consensus on this topic to complete the Job MIB. This issue should be discussed and an agreement reached in Maui. I would like to add this discussion to the PWG general topics on Wednesday morning. Ron Bergman Dataproducts Corp. From rbergma at dpc.com Wed Jan 14 21:18:40 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG OID Structure Proposals In-Reply-To: <199801150202.AA10325@interlock2.lexmark.com> Message-ID: <199801150202.AA10328@interlock2.lexmark.com> Don, I did not intend to eliminate this combination and I would prefer it over the combination that includes the standard / experimental. Note that reserving spaces for future related projects does not have to be a requirement. It happens automatically, whether you like it or not. Also, an experimental branch (arc) could be defined (maybe at 100 which would allow 99 funtional types), if this is desired. Ron Bergman Dataproducts Corp. On Wed, 14 Jan 1998 don@lexmark.com wrote: > > What about a combination of the functional and project structure that > reserves > spaces for future projects related to existing projects? For example: > > ....2699.1 = MIBs > ....2699.1.1 = Job Monitoring > ....2699.1.1.1 = Job MIB > ....2699.1.1.2 = Job MIB extensions #1 > ....2699.1.1.3 = Job MIB extensions #2 > ....2699.1.2 = Finisher > ....2699.1.2.1 = Finisher MIB > ....2699.1.2.2 = Finisher MIB extensions > ....2699.1.3 = Printer > ....2699.1.3.1 = Printer MIB II > ....2699.1.3.2 = Printer MIB II extensions > ....2699.2 = Protocols > ....2699.2.1 = IPP > ....2699.2.1.1 = IPP operations > ....2699.2.1.2 = IPP Attributes > > I think this has the advantages of both. The only downside is that > the structure is one digit longer than either --- not really much > of a problem. > > ********************************************** > * Don Wright don@lexmark.com * > * Product Manager, Strategic Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > > > > > rbergma%dpc.com@interlock.lexmark.com > 01/14/98 11:49 AM > > > To: jmp%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright) > bcc: Don Wright > Subject: JMP> PWG OID Structure Proposals > > > > > There was considerable email discussion last December regarding the > structure of the OIDs in the PWG enterprises subtree, without a final > resolution. Here is a summary of the proposed PWG OID structures: > 1. A flat structure where each item, whether it is a MIB, operations, > attributes, etc, is assigned a number under 2699. For example: > ....2699.1 = Job Monitoring MIB > ....2699.2 = Finisher MIB > ....2699.3 = Printer MIB-2 > ....2699.4 = IPP operations > ....2699.5 = IPP Attributes > ....2699.6 = Finisher MIB extensions > ....2699.7 = Job Monitoring MIB extensions > The next number in sequence is assigned as needed. > Experimental OIDs could be indicated by numbers in a higher range. > For example, numbers of 10000 or greater would be experimental. > Or, until a document is released as official, either as a IETF RFC > or by some other approved means, it is still regarded as > experimental. In this latter case, some numbers may never become > approved. > 2. A project structure where related items are grouped together. In > this case the above would be grouped: > ....2699.1 = Job Monitoring > ....2699.1.1 = Job Monitoring MIB > ....2699.1.2 = Job Monitoring MIB extensions > ....2699.2 = Finisher > ....2699.2.1 = Finisher MIB > ....2699.2.2 = Finisher MIB extensions > ....2699.3 = Printer > ....2699.3.1 = Printer MIB-2 > ....2699.4 = IPP > ....2699.4.1 = IPP operations > ....2699.4.2 = IPP Attributes > 3. A function structure where items are grouped by document type. > Again, the above items would now be grouped: > ....2699.1 = MIBs > ....2699.1.1 = Job Monitoring MIB > ....2699.1.2 = Finisher MIB > ....2699.1.3 = Printer MIB-2 > ....2699.1.4 = Finisher MIB extensions > ....2699.1.5 = Job Monitoring MIB extensions > ....2699.2 = Protocols > ....2699.2.1 = IPP > ....2699.2.1.1 = IPP operations > ....2699.2.1.2 = IPP Attributes > 4. A major grouping by experimental and standard items. > ....2699.1 = PWG Standard OIDs > ....2699.2 = PWG Experimental OIDs > Combinations of the above are also possible. For example, the > experimental / standard grouping could be followed by the function > structure and followed by the project structure. (It is an exercise for > the reader to create this figure using the above items.) > This subject was also discussed in the JMP session at both the Boulder > and LA meetings. In the Boulder meeting, Harry proposed the project > structure and I proposed the flat structure. In both meetings there > was not much excitement for this topic and the general agreement was > the flat structure was good enough. > The current Job Monitoring MIB follows the project structure and > results in the following OIDs: > First MIB object jmGeneralJobSetIndex: (x = Table index) > 1.3.6.1.4.1.2699.1.1.1.1.1.1.1.x (15 OID positions) > Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) > 1.3.6.1.4.1.2699.1.1.1.4.1.1.4.x.y.z (17 OID positions) > > Using the combinations of structures 2, 3, and 4 these OIDs are: > First MIB object jmGeneralJobSetIndex: (x = Table index) > 1.3.6.1.4.1.2699.1.1.1.1.1.1.1.1.1.x (17 OID positions) > Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) > 1.3.6.1.4.1.2699.1.1.1.1.1.4.1.1.4.x.y.z (19 OID positions) > > Using the flat structure provides the shortest OIDs: > First MIB object jmGeneralJobSetIndex: (x = Table index) > 1.3.6.1.4.1.2699.1.1.1.1.1.1.x (14 OID positions) > Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices) > 1.3.6.1.4.1.2699.1.1.4.1.1.4.x.y.z (16 OID positions) > > While I believe that the combination of all three structures provides > the most information and flexibility, do we really need all this > capability? There is usually some elegance in simplicity. How many > projects will require an OID assignment in the future? > As should be evident, my preference is for the flat model. But I do not > see a major implementation difference in any of the proposals. We do > need to reach a group consensus on this topic to complete the Job MIB. > This issue should be discussed and an agreement reached in Maui. I would > like to add this discussion to the PWG general topics on Wednesday > morning. > > Ron Bergman > Dataproducts Corp. > > > > > > > > > > > From don at lexmark.com Wed Jan 14 21:39:17 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG OID Structure Proposals In-Reply-To: PWG OID Structure Proposals> Message-ID: <199801150302.AA11786@interlock2.lexmark.com> Ron Bergman said: >I did not intend to eliminate this combination and I would prefer it over >the combination that includes the standard / experimental. > >Note that reserving spaces for future related projects does not have to be >a requirement. It happens automatically, whether you like it or not. I agree. I didn't mean we had to "reserve" any space. This method does it by its very nature. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From rbergma at dpc.com Thu Jan 15 12:21:37 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:13 2009 Subject: JMP> Job Submission Protocol Mapping version 05 Message-ID: <199801150302.AA11786@interlock2.lexmark.com> I finally fixed my tools to create a text file from a Word document! I have loaded the new Jib Submission Protocol mapping document that was sent out on email recently. See ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP05.DOC (.TXT) Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Tue Jan 20 12:07:07 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> FWD: Protocol Action: IETF Policy on Character Sets and Message-ID: <3.0.1.32.19980120090707.010f3ae0@garfield> >Date: Tue, 20 Jan 1998 08:34:19 PST >From: The IESG >Subject: Protocol Action: IETF Policy on Character Sets and Languages to BCP >Sender: scoya@cnri.reston.va.us >To: IETF-Announce:;;@sigurd.innosoft.com@cp10.es.xerox.coM >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ietf-charsets@innosoft.com > > > >The IESG has approved publication of the following Internet-Drafts: > > o IETF Policy on Character Sets and Languages > for publication as a BCP. > > o IANA Charset Registration Procedure > for publication as a BCP. > > > o UTF-8, a transformation format of ISO 10646 > for publication as a Proposed Standard. > >The IESG contact person is Keith Moore. > > >Technical Summary > > This set of documents specifies a consistent, useful policy for the > IETF with regard to the use of character sets and language > information in IETF standards. > > In particular, it specifies that protocols MUST be able to use > the UTF-8 charset in human-readable text strings (support for > other charsets is optional), and MUST be able to provide language > tags for such text, in order to be successfully submitted to IETF > standards processes without approval of a variance procedure. > >Working Group Summary > > The policy has been reviewed at a special BOF at the Munich IETF > and in numerous working groups; there seems to be rough consensus > on the policy as stated. > > No objections were raised during IETF Last Call. > >Protocol Quality > > These documents have been reviewed for the IESG by Keith Moore. > > >NOTE TO RFC EDITOR: >draft-yergeau-utf8-rev-01.txt contains an instance of MUST (all caps). >The IESG requests this word be lower case. > > > From don at lexmark.com Thu Jan 22 00:55:34 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG> Meeting Charges Message-ID: <199801220634.AA16323@interlock2.lexmark.com> fyi.... Don ---------------------- Forwarded by Don Wright on 01/22/98 12:55 AM --------------------------- From: lstein%fapo.com@interlock.lexmark.com on 01/21/98 02:58 PM PST To: p1394%pwg.org@interlock.lexmark.com, pwg%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright) bcc: Don Wright Subject: PWG> Meeting Charges Aloha All, The meeting charge for the January PWG meetings will be $36.00 per person per meeting day. This includes the room rental, AV equipment, power strips, food and beverage. Hopefully, to make things easier, Warp Nine will process all the meeting charges through our card service. This way we don't have to have the hotel involved at all. Yes Don, we will provide receipts if requested. Please print out this email, fill in the questions and bring it to the meeting. Checks made out to Warp Nine or cash made out to Larry is fine also. Thanks, Larry ________________________________________________________________ January PWG Meeting Charges # of Meetings Charge 1 day $36 2 days $72 3 days $108 4 days $144 5 days $180 Name: Company: Phone Number: Card Type: Visa MasterCard American Express Card number: Expiration date: Total Meeting Days: Total Meeting Charge: Name on Card (if different): Street address or PO box no. credit card is billed to: Zip code credit card is billed to: Receipt requested? Yes No Fax number for receipt: Signature: *************************************************************** Larry A. Stein Phone: (619)292-2742 Warp Nine Engineering Fax: (619)292-8020 Web: http://www.fapo.com *************************************************************** From hastings at cp10.es.xerox.com Thu Jan 22 17:35:53 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Job MIB posted and sent as an Internet-Draft Message-ID: <3.0.1.32.19980122143553.011a7ad0@garfield> After two weeks of mud wrestling with WORD97, I've succeeded in producing a text file that meets the IETF requirements for an Internet-Draft (and an RFC). Ron and I have agreed that I should send it as it is as an Internet-Draft today. I've kept the flat OID structure as agreed at the JMP meeting. If we decide to change to another structure at the PWG meeting next week, we can re-issue another Internet-Draft before requesting the IESG to process it as an Informational RFC. ***************************************************************************** So one of the agenda items for next week's (1/28/98) PWG meeting is: Ok to request the IESG to process the Internet-Draft as an Information RFC? In other words, is this version the approved PWG Job Monitoring MIB standard? ***************************************************************************** I've simplified the .doc, so that it is all fixed pitch Courier New. I've also eliminated the bolding, since it was hard to read with CourierNew. The table of contents and index agree with the page numbers. All the cross-references are correct. There are almost no changes since the version that I posted last December 21. One addition is to explain why implementors should join the jmp DL, which had support on the mailing list. One change was to shorten the processingMessageNaturalLanguageTag attribute name to processingMessageNaturalLangTag. All other changes were simply formatting. I've tried to reduce the number of bad page breaks. So the .pdf files have lines numbers and the number of lines agree with the text/plain version (which does not have line numbers). In order to compile with SMICng, I commented out the attribute description by simply replacing two leading spaces with --. So now the jmp-mib.txt file compiles with SNICng, Epilogue 6.0, and mosy 7.1 with no errors and only warnings about the TCs being defined but not used (since they are part of the description within the AttributeTC itself). The files are: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/mibvaria.dot The files with "rev" have revision marks. The .mib file has the headers and footers stripped off. I've called it version 0.90 on the cover sheet of the one with revisions. The body of the documents calls it version 1.0. The version without revision marks and the .txt do not have the cover sheet. I've copied the 0.89 version files from December 22 to: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/historical/historical-089/ if you want to see the changes that were made in December. (Since I forgot to populate the historical directories when I posted the files in December, they have today's date). (There is no version 0.88 - that was just a proof reading version that I sent to Ron and Harry before the December meeting). Tom From hastings at cp10.es.xerox.com Thu Jan 22 19:57:28 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Job MIB posted and sent as an Internet-Draft In-Reply-To: <3.0.1.32.19980122143553.011a7ad0@garfield> Message-ID: <3.0.1.32.19980122165728.011a1770@garfield> My previous e-mail indicated that I had sent the posted Job Monitoring MIB as an Internet-Draft. But just as I was sending it, I realized that the Abstract and the Introduction state that the draft "has been approved as a PWG standard". Ron and I would like to verify that the Job Monitoring MIB that I posted today on the PWG server has been approved as a PWG standard at the PWG next week, before we send the Internet-Draft that says that it is an approved PWG standard. So I have NOT sent the Internet-Draft, rather than changing the following Abstract and Introduction paragraphs: Abstract This document has been developed and approved by the Printer Working Group (PWG) as a PWG standard. It is intended to be distributed as an Informational RFC. This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. 1.0 Introduction This specification defines an official Printer Working Group (PWG) [PWG] standard SNMP MIB for the monitoring of jobs on network printers. This specification is being published as an IETF Information Document for the convenience of the Internet community. In consultation with the IETF Application Area Directors, it was concluded properly belongs as an Information document, because this MIB monitors a service node on the network, rather than a network node proper. Please review the posted Job Monitoring MIB before next week's PWG meeting, so that we can agree at the PWG meeting that it is "an approved PWG standard". Thanks, Tom At 14:35 01/22/1998 PST, Tom Hastings wrote: >After two weeks of mud wrestling with WORD97, I've succeeded in producing >a text file that meets the IETF requirements for an Internet-Draft (and >an RFC). > >Ron and I have agreed that I should send it as it is as an Internet-Draft >today. > >I've kept the flat OID structure as agreed at the JMP meeting. If we decide >to change to another structure at the PWG meeting next week, we can >re-issue another Internet-Draft before requesting the IESG to process it >as an Informational RFC. > >***************************************************************************** >So one of the agenda items for next week's (1/28/98) PWG meeting is: > > Ok to request the IESG to process the Internet-Draft as an Information RFC? > In other words, is this version the approved PWG Job Monitoring MIB >standard? >***************************************************************************** > >I've simplified the .doc, so that it is all fixed pitch Courier New. >I've also eliminated the bolding, since it was hard to read with >CourierNew. > >The table of contents and index agree with the page numbers. All the >cross-references are correct. > >There are almost no changes since the version that I posted last December 21. > >One addition is to explain why implementors should join the jmp DL, >which had support on the mailing list. > >One change was to shorten the processingMessageNaturalLanguageTag >attribute name to processingMessageNaturalLangTag. > >All other changes were simply formatting. I've tried to reduce the >number of bad page breaks. > >So the .pdf files have lines numbers and the number of lines agree >with the text/plain version (which does not have line numbers). > >In order to compile with SMICng, I commented out the attribute >description by simply replacing two leading spaces with --. > >So now the jmp-mib.txt file compiles with SNICng, Epilogue 6.0, and mosy 7.1 >with no errors and only warnings about the TCs being defined but not >used (since they are part of the description within the AttributeTC itself). > >The files are: > >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.mib >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp.dic >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/mibvaria.dot > >The files with "rev" have revision marks. >The .mib file has the headers and footers stripped off. > >I've called it version 0.90 on the cover sheet of the one >with revisions. The body of the documents calls it version 1.0. >The version without revision marks and the .txt do not have the >cover sheet. > >I've copied the 0.89 version files from December 22 to: > >ftp://ftp.pwg.org/pub/pwg/jmp/mibs/historical/historical-089/ > >if you want to see the changes that were made in December. >(Since I forgot to populate the historical directories when I posted >the files in December, they have today's date). > >(There is no version 0.88 - that was just a proof reading version that >I sent to Ron and Harry before the December meeting). > >Tom > > > > From hastings at cp10.es.xerox.com Thu Jan 22 21:15:17 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> RE: PWG> PWG OID Structure Proposals [the case for a flat In-Reply-To: <199801141750.AA15362@emulex.emulex.com> Message-ID: <3.0.1.32.19980122181517.0118f610@garfield> We could obtain the objectives that you cite (of a MIB walk getting a MIB and all its extensions before encountering a different MIB) with a flat OID structure by assigning a block of OIDs for the first use that thinks it might need additional OIDs for which there is some advantage to having adjacent OIDs as you suggest. So for example, the Job Monitoring MIB could be assigned, say, the first 5 OID arcs, 1-5, instead of just 1. On the other hand, for an extension to the Job Monitoring MIB, say some new tables, why would we not continue with the same OID sub-tree? The Job Monitoring MIB assigns the following under: ... enterprises pwg(2699) jobmonMIB(1): jobmonMIBObjects(1) jobmonMIBNotifications(2) jobmonMIBConformance(3) If we add new objects as an extension, they will be under 1.1 If we add traps as an extension they will be under 1.2 The extensions WOULD NOT at the same level as jobmonMIB(1). In other words, why would extensions to the Job Monitoring MIB use additional OIDs at the jobmonMIB level at all? As another example, the Finisher MIB is an extension to the Printer MIB, so that it will use OIDs in the Printer MIB sub-tree, not start a new OID sub-tree. So I think that the suggestion of extension MIBs using OIDs at the same level as the MIB it was extending is confusing us. It won't happen. So I remain convinced that a flat structure has all good points and no bad points. The good points for a flat structure: 1. Its simplest. 2. It requires no further agreement in order to use it in the Job Monitoring MIB. 3. If we add some structure, we will have to write it down, agree to it, maintain it, etc. The flat approach requires no such additional document, effort, or agreement. We can publish the Job Monitoring MIB immediately with no further discussion. 4. I have lived through two corporations attempting to set up structure: Digital and Xerox. In both cases, none of the rest of the structure got used. Its too hard to predict the future. So defining structure is a waste of time and does not help anything. 5. An extensions to the Job Monitoring MIB that need OIDs will be assigned in the same sub-tree, so that a MIB walk will hit all Job Monitoring MIB extensions before hitting OIDs from another PWG MIB (if there ever is one). 6. Its shortest in number of OIDs over the wire. The bad points for a flat OID structure: 1. I can't think of any. Comments? Tom At 09:47 01/14/1998 PST, Nixon, Bob wrote: > >I'm not educated enough to have an opinion on the PWG MIB structure, but >here is a point to consider... > >Feedback from our customers has often indicated that "MIB walk" >(sequential access in OID order) needs to present a usable view of a >system and / or its subsystems. This would argue against a "flat" or > "functional" organization because a large body of unrelated information >may lie (in the examples, does lie) sequentially between the MIB for a >project ("subsystem"?) and its later-developed extensions. The "project" >organization seems better able to support this goal. > > - Bob Nixon. Emulex Network Systems > ---------- >From: Ron Bergman[SMTP:rbergma@dpc.com] >Sent: Wednesday, January 14, 1998 8:49 AM >To: jmp; pwg >Subject: PWG> PWG OID Structure Proposals > > ---------------------------------------------------- >There was considerable email discussion last December regarding the >structure of the OIDs in the PWG enterprises subtree, without a final >resolution. Here is a summary of the proposed PWG OID structures: > > 1. A flat structure where each item, whether it is a MIB, operations, > attributes, etc, is assigned a number under 2699. For example: > > > From b_nixon at emulex.com Fri Jan 23 12:05:00 1998 From: b_nixon at emulex.com (Nixon, Bob) Date: Wed May 6 14:00:13 2009 Subject: JMP> RE: PWG> PWG OID Structure Proposals [th Message-ID: <199801231709.AA19876@emulex.emulex.com> If there is no need to add extensions at the "top" level, my observation noted way below is irrelevant. Flat is beautiful (but then, what do I know about art?) - Bob. ---------- From: Tom Hastings[SMTP:hastings@cp10.es.xerox.com] Sent: Thursday, January 22, 1998 6:15 PM To: Nixon, Bob; jmp; pwg; Ron Bergman Subject: RE: PWG> PWG OID Structure Proposals [the case for a flatstructure] ---------------------------------------------------- We could obtain the objectives that you cite (of a MIB walk getting a MIB and all its extensions before encountering a different MIB) with a flat OID structure by assigning a block of OIDs for the first use that thinks it might need additional OIDs for which there is some advantage to having adjacent OIDs as you suggest. So for example, the Job Monitoring MIB could be assigned, say, the first 5 OID arcs, 1-5, instead of just 1. On the other hand, for an extension to the Job Monitoring MIB, say some new tables, why would we not continue with the same OID sub-tree? The Job Monitoring MIB assigns the following under: ... enterprises pwg(2699) jobmonMIB(1): jobmonMIBObjects(1) jobmonMIBNotifications(2) jobmonMIBConformance(3) If we add new objects as an extension, they will be under 1.1 If we add traps as an extension they will be under 1.2 The extensions WOULD NOT at the same level as jobmonMIB(1). In other words, why would extensions to the Job Monitoring MIB use additional OIDs at the jobmonMIB level at all? As another example, the Finisher MIB is an extension to the Printer MIB, so that it will use OIDs in the Printer MIB sub-tree, not start a new OID sub-tree. So I think that the suggestion of extension MIBs using OIDs at the same level as the MIB it was extending is confusing us. It won't happen. So I remain convinced that a flat structure has all good points and no bad points. The good points for a flat structure: 1. Its simplest. 2. It requires no further agreement in order to use it in the Job Monitoring MIB. 3. If we add some structure, we will have to write it down, agree to it, maintain it, etc. The flat approach requires no such additional document, effort, or agreement. We can publish the Job Monitoring MIB immediately with no further discussion. 4. I have lived through two corporations attempting to set up structure: Digital and Xerox. In both cases, none of the rest of the structure got used. Its too hard to predict the future. So defining structure is a waste of time and does not help anything. 5. An extensions to the Job Monitoring MIB that need OIDs will be assigned in the same sub-tree, so that a MIB walk will hit all Job Monitoring MIB extensions before hitting OIDs from another PWG MIB (if there ever is one). 6. Its shortest in number of OIDs over the wire. The bad points for a flat OID structure: 1. I can't think of any. Comments? Tom At 09:47 01/14/1998 PST, Nixon, Bob wrote: > >I'm not educated enough to have an opinion on the PWG MIB structure, but >here is a point to consider... > >Feedback from our customers has often indicated that "MIB walk" >(sequential access in OID order) needs to present a usable view of a >system and / or its subsystems. This would argue against a "flat" or > "functional" organization because a large body of unrelated information >may lie (in the examples, does lie) sequentially between the MIB for a >project ("subsystem"?) and its later-developed extensions. The "project" >organization seems better able to support this goal. > > - Bob Nixon. Emulex Network Systems > ---------- >From: Ron Bergman[SMTP:rbergma@dpc.com] >Sent: Wednesday, January 14, 1998 8:49 AM >To: jmp; pwg >Subject: PWG> PWG OID Structure Proposals > > ---------------------------------------------------- >There was considerable email discussion last December regarding the >structure of the OIDs in the PWG enterprises subtree, without a final >resolution. Here is a summary of the proposed PWG OID structures: > > 1. A flat structure where each item, whether it is a MIB, operations, > attributes, etc, is assigned a number under 2699. For example: > > > From don at lexmark.com Fri Jan 23 12:53:33 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG OID Structure Proposals [the case for a flat structure] Message-ID: <199801231754.AA19814@interlock2.lexmark.com> Tom Hastings said: >3. If we add some structure, we will have to write it down, agree to it, >maintain it, etc. The flat approach requires no such additional document, >effort, or agreement. We can publish the Job Monitoring MIB immediately >with no further discussion. Imagine that! Thinking about what we are doing before doing it. I'd rather set a direction that is flexible and usable up front rather than setting and re-setting it every other month. >4. I have lived through two corporations attempting to set up structure: >Digital and Xerox. In both cases, none of the rest of the structure >got used. Its too hard to predict the future. So defining structure >is a waste of time and does not help anything. One of the core concepts of the OID space is to allow for distribution name space administration. I guess the PWG must be at the end of the world and therefore there is no future reason to worry about distributed name space management beyond us and our OID! I set up the Lexmark OID space and management process; it uses a hierarchical approach. I happy with the results. >6. Its shortest in number of OIDs over the wire. Who cares about this small difference? Are they charging for electrons these days? ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From hastings at cp10.es.xerox.com Fri Jan 23 18:02:19 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Job Submission Protocol Mapping version 06 Message-ID: <3.0.1.32.19980123150219.00cf4e30@garfield> I've updated the IPP mapping to agree with the latest (final) Model. I've added a few more attributes that DPA maps, so that it is complete now. Ron asked me to proof read the mapping document one more time. I've re-ordered the attributes and objects, so that they are in the order of the JMP spec. That makes it much easier to compare with the JMP spec and between protocols. I did those moves with revisions turned off. The rest of my comments are with revisions turned on. I also spell checked it using the jmp.dic to make sure that the object and attribute names agree with JMP. I've updated the jmp.dic in the mibs sub-directory where it had been, so that we only have one copy. I've called this version 6. Since Ron has forwared version 5 as an Internet-Draft, I've added one to the file name to give: I've posted the results as: ftp://ftp.pwg.org/pub/pwg/jmp/specs/jmpmap06-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/specs/jmpmap06-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/specs/jmpmap06.doc ftp://ftp.pwg.org/pub/pwg/jmp/specs/jmpmap06.pdf ftp://ftp.pwg.org/pub/pwg/jmp/specs/jmpmap06.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp.dic Only the jmpmap06.pdf has line numbers. I'll bring 30 copies to the PWG meeting, for the 10 minute JMP status on Wednesday (as well as 30 copies of the Jobmon MIB itself). Tom From hastings at cp10.es.xerox.com Fri Jan 23 18:20:38 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:13 2009 Subject: JMP> Re: PWG> PWG OID Structure Proposals [the case for a flat In-Reply-To: <199801231754.AA19814@interlock2.lexmark.com> Message-ID: <3.0.1.32.19980123152038.0118fe70@garfield> At 09:53 01/23/1998 PST, don@lexmark.com wrote: > > >Tom Hastings said: > >>3. If we add some structure, we will have to write it down, agree to it, >>maintain it, etc. The flat approach requires no such additional document, >>effort, or agreement. We can publish the Job Monitoring MIB immediately >>with no further discussion. > >Imagine that! Thinking about what we are doing before doing it. I'd >rather set a direction that is flexible and usable up front rather than >setting and re-setting it every other month. Actually, we have been trying to write something down for two months already and changing it every time. I am afraid that this will continue. With the flat scheme we are done now. We don't need to write down anything. We don't need to continue this debate. And we won't have to change anything each month. Each need for a PWG OID gets to define their own sub-structure (as the Job Mon MIB has done following standard MIB practice). This is the ultimate in flexibility and there is no need to continue this debate with a flat structure. Also continuing this debate will futher delay getting this MIB to the IESG and getting them to assign an RFC. Putting it another way, setting up a structure, writing it down, reviewing it, agreeing to it, maintaining it, is buracracy that the PWG doesn't need. So far, I haven't seen one advantage to having more structure and a lot of disadvantages: 1. Its process overhead that we don't need. 2. It will further delay the Job Monitoring MIB. 3. It doesn't buy anything. 4. It has the risk of not being exactly what the future will want/need. Can you state one advantage to having more structure? >>4. I have lived through two corporations attempting to set up structure: >>Digital and Xerox. In both cases, none of the rest of the structure >>got used. Its too hard to predict the future. So defining structure >>is a waste of time and does not help anything. > >One of the core concepts of the OID space is to allow for distribution >name space administration. I guess the PWG must be at the end of the >world and therefore there is no future reason to worry about >distributed name space management beyond us and our OID! > >I set up the Lexmark OID space and management process; it uses a >hierarchical approach. I happy with the results. What advantages did it give you? How many OIDs have you assigned? >>6. Its shortest in number of OIDs over the wire. > >Who cares about this small difference? Are they charging for electrons >these days? I agree that it is a small point (that is why I put it last). >********************************************** >* Don Wright don@lexmark.com * >* Product Manager, Strategic Alliances * >* Lexmark International * >* 740 New Circle Rd * >* Lexington, Ky 40550 * >* 606-232-4808 (phone) 606-232-6740 (fax) * >********************************************** > > > > From don at lexmark.com Mon Jan 26 11:28:47 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:13 2009 Subject: JMP> IPP> Re: PWG> PWG OID Structure Proposals [the case for a flat In-Reply-To: PWG OID Structure Proposals [the case for a flat> Message-ID: <3.0.1.32.19980126082847.00e20de0@garfield> Tom Hastings said: >Actually, we have been trying to write something down for two months >already and changing it every time. I am afraid that this will continue. The only writing I've seen is e-mails. I haven't seen an actual compilation using different structures. >What advantages did it give you? Distributed name space management with some logic to it. Adapters are next to adapters, printer are next to printers, etc. I don't have adapter MIBs in between printers, in between stuff I can't talk about. >How many OIDs have you assigned? hundreds I'm tired of arguing about this. Go ahead with a flat space and paint yourselves in a corner later. Perhaps we can claim PWG OIDs are secure -- "security by confusion." I reserve the right to say "I told you so." Don From Internet-Drafts at ns.ietf.org Wed Jan 28 03:10:48 1998 From: Internet-Drafts at ns.ietf.org (Internet-Drafts@ns.ietf.org) Date: Wed May 6 14:00:13 2009 Subject: JMP> PMP> I-D ACTION:draft-ietf-printmib-job-protomap-00.txt Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Title : Job Submission Protocol Mapping Recommendations Author(s) : R. Bergman Filename : draft-ietf-printmib-job-protomap-00.txt Pages : 19 Date : 26-Jan-98 This Internet-Draft defines the recommended mapping for many currently popular Job submission protocols to objects and attributes the Job Monitoring MIB. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-protomap-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-protomap-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-protomap-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From carterk at us.ibm.com Mon Feb 2 12:37:18 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:13 2009 Subject: JMP> PWG meeting in Austin on 3/2-6 Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From mark at mtesoft.com Tue Feb 3 00:08:59 1998 From: mark at mtesoft.com (Mark T. Edmead) Date: Wed May 6 14:00:13 2009 Subject: JMP> RE: PWG> PWG meeting in Austin on 3/2-6 Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> Keith: I will be attending. 1) What meeting dates will you attend? 3-2 and 3-3 2) Will you stay at the Hyatt hotel? Yes 3) If you are staying at the Hyatt, what are your arrival and departure dates? Probably arrive the day before and leave the day after. Regards, Mark Edmead **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Monday, February 02, 1998 9:37 AM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Print gurus, > > I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the > scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. > > HOTEL INFORMATION > > Hyatt Regency Austin (located on Town Lake in downtown Austin). > Phone: 512-477-1234 > $101 per night (single occupancy). > Meeting room charge will be based on meeting attendance per day (see PING > INFORMATION) > Cab fare from airport is $12-14. > Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 > blocks for the athletically inclined). > Restaurants within 1 block of the hotel include: Threadgills (famous for their > home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al > Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). > The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) > and other restaurants are within a short drive of the hotel. > For you olympians, there is a public jogging trail that goes by the hotel and > around the lake. > > PWG MEETING AGENDA > > Here is the agenda proposed by Don Wright: > > Monday (3/2), Tuesday (3/3): > -- 1394 Printing > Wednesday (3/4) AM: > -- PWG overview session > -- Discussion on NC Printing > Wednesday (3/4) PM: > -- IPP > Thursday (3/5): > -- IPP > Friday (3/6): > -- Finisher > -- Job MIB Traps > > Please address any questions on the PWG agenda to Don Wright. Please address > any questions on a working group agenda to the working group chair. > > PING INFORMATION > > Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following > information: > > 1) What meeting dates will you attend? > 2) Will you stay at the Hyatt hotel? > 3) If you are staying at the Hyatt, what are your arrival and departure dates? > > On 2/11, I'll provide the information to the hotel, distribute a list of > attendees to the PWG distribution lists, and provide you with the meeting room > costs per day. On 2/12 you may start making your reservations at the Hyatt > hotel under the name "Printer Working Group". > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 From rbergma at dpc.com Tue Feb 3 12:07:05 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:14 2009 Subject: JMP> Internet Draft for Jpb Submission Protocol Mappings Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> DQpUaGlzIGlzIGEgc3VibWlzc2lvbiBvZiB0aGUgc2Vjb25kIEludGVybmV0 LURyYWZ0IG9mIGEgY29tcGFuaW9uIGRvY3VtZW50DQp0byB0aGUgSm9iIE1v bml0b3JpbmcgTUlCIHRoZSBwcm92aWRlcyBhIG1hcHBpbmcgb2YgSm9iIFN1 Ym1pc3Npb24NClByb3RvY29scyB0byB0aGUgSm9iIE1JQjoNCg0KDQogICAg ICAgVGl0bGUgICAgIDogSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGlu ZyBSZWNvbW1lbmRhdGlvbnMgZm9yDQogICAgICAgICAgICAgICAgICAgdGhl IEpvYiBNb25pdG9yaW5nIE1JQiAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICBBdXRob3IocykgOiBSLiBCZXJnbWFuDQogICAgICAgRmlsZW5h bWUgIDogZHJhZnQtaWV0Zi1wcmludG1pYi1qb2ItcHJvdG9tYXAtMDEudHh0 DQogICAgICAgUGFnZXMgICAgIDogMjINCiAgICAgICBEYXRlICAgICAgOiBG ZWJydWFyeSAyLCAxOTk4DQoNCg0KVGhlIEFic3RyYWN0IGlzOg0KDQogICAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgZGVmaW5lcyB0aGUgcmVjb21tZW5kZWQg bWFwcGluZyBmb3IgbWFueQ0KICAgICBjdXJyZW50bHkgcG9wdWxhciBKb2Ig c3VibWlzc2lvbiBwcm90b2NvbHMgdG8gb2JqZWN0cyBhbmQNCiAgICAgYXR0 cmlidXRlcyB0aGUgSm9iIE1vbml0b3JpbmcgTUlCLg0KDQoNCglUaGFuayB5 b3UsDQoJUm9uIEJlcmdtYW4NCglGb3IgdGhlIHByaW50bWliIFdHDQoNCg0K LS0NCg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIEJlcmdtYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIERhdGFwcm9kdWN0cyBDb3JwLg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFy eSAyLCAxOTk4DQoNCg0KICAgICAgICAgICAgIEpvYiBTdWJtaXNzaW9uIFBy b3RvY29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25zDQogICAgICAgICAgICAg ICAgICAgICAgIGZvciB0aGUgSm9iIE1vbml0b3JpbmcgTUlCDQoNCiAgICAg ICAgICAgICAgIDxkcmFmdC1pZXRmLXByaW50bWliLWpvYi1wcm90b21hcC0w MS50eHQ+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDIsIDE5OTgNCg0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg ICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0LiAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nDQogICAgIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBh cmVhcywNCiAgICAgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhh dCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgICB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXgNCiAgICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0KICAgICBkb2N1 bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMNCiAgICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQogICAg IHByb2dyZXNzIi4NCg0KICAgICBUbyBsZWFybiB0aGUgY3VycmVudCBzdGF0 dXMgb2YgYW55IEludGVybmV0LURyYWZ0LCBwbGVhc2UgY2hlY2sgdGhlDQog ICAgICIxaWQtYWJzdHJhY3RzLnR4dCIgbGlzdGluZyBjb250YWluZWQgaW4g dGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgICAgRGlyZWN0b3JpZXMg b24gZnRwLmlzLmNvLnphIChBZnJpY2EpLCBuaWMubm9yZHUubmV0IChFdXJv cGUpLA0KICAgICBtdW5uYXJpLm96LmF1IChQYWNpZmljIFJpbSksIGRzLmlu dGVybmljLm5ldCAoVVMgRWFzdCBDb2FzdCksIG9yDQogICAgIGZ0cC5pc2ku ZWR1IChVUyBXZXN0IENvYXN0KS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBYnN0cmFjdA0KDQogICAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgZGVmaW5lcyB0aGUgcmVjb21tZW5kZWQgbWFwcGluZyBmb3IgbWFueQ0K ICAgICBjdXJyZW50bHkgcG9wdWxhciBKb2Igc3VibWlzc2lvbiBwcm90b2Nv bHMgdG8gb2JqZWN0cyBhbmQNCiAgICAgYXR0cmlidXRlcyBpbiB0aGUgSm9i IE1vbml0b3JpbmcgTUlCLg0KDQoNCg0KDQoNCg0KVEFCTEUgT0YgQ09OVEVO VFMNCg0KMi4wICBMSU5FIFBSSU5URVIgREFFTU9OIChMUFIvTFBEKSBQUk9U T0NPTC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQoyLjEgIGptSm9i U3VibWlzc2lvbklEIE1hcHBlZCB0byBMUFIvTFBELi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjQNCjIuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8g TFBSL0xQRC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NQ0KMi4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gTFBSL0xQRC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQoyLjQgIFRoZSBBdHRy aWJ1dGUgR3JvdXAgTWFwcGVkIHRvIExQRC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjUNCjMuMCAgQVBQTEVUQUxLIFBST1RPQ09MLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDFdDQwNCklOVEVSTkVU LURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg ICAgICAgICBGZWIgMiwgMTk5OA0KDQoNCg0KDQozLjEgIGptSm9iU3VibWlz c2lvbklEIE1hcHBlZCB0byBBcHBsZVRhbGsuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjYNCjMuMiAgT3RoZXIgQXBwbGVUYWxrIE1hcHBpbmdzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KNC4w ICBJTlRFUk5FVCBQUklOVElORyBQUk9UT0NPTCAoSVBQKS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQo0LjEgIGptSm9iU3VibWlzc2lv bklEIE1hcHBlZCB0byBJUFAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjcNCjQuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gSVBQLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0KNC4zICBP dGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gSVBQLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi43DQo0LjQgIFRoZSBBdHRyaWJ1dGUgR3Jv dXAgTWFwcGVkIHRvIElQUC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjgNCjUuMCAgSU5URUxMSUdFTlQgUFJJTlRFUiBEQVRBIFNUUkVBTSAo SVBEUykuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOQ0KNS4xICBqbUpv YlN1Ym1pc3Npb25JZCBNYXBwZWQgdG8gSVBEUy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi45DQo1LjIgIFRoZSBBdHRyaWJ1dGUgR3JvdXAg TWFwcGVkIHRvIElQRFMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTANCjYuMCAgRE9DVU1FTlQgUFJJTlRJTkcgQVBQTElDQVRJT04gKERQQSku Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KNi4xICBqbUpvYlN1 Ym1pc3Npb25JRCBNYXBwZWQgdG8gRFBBLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjEwDQo2LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIERQ QS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEN CjYuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRvIERQQS4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KNi40ICBUaGUgQXR0cmli dXRlIEdyb3VwIE1hcHBlZCB0byBEUEEuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExDQo3LjAgIE5PVkVMTCBESVNUUklCVVRFRCBQUklOVCBT RVJWSUNFIChORFBTKS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCjcu MSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIE5EUFMuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KNy4yICBqbUpvYkluZGV4IE1h cHBlZCB0byBORFBTLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjEzDQo3LjMgIE90aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0byBO RFBTLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCjcuNCAg VGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gTkRQUy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNA0KOC4wICBQUklOVEVSIEpPQiBMQU5H VUFHRSAoUEpMKS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjE1DQo4LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBQSkwu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCjguMiAgam1K b2JJbmRleCBNYXBwZWQgdG8gUEpMLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xNg0KOC4zICBPdGhlciBNSUIgT2JqZWN0cyBN YXBwZWQgdG8gUEpMLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjE2DQo4LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIFBKTC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYNCjkuMCAgUE9TVFND UklQVC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xNg0KOS4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBw ZWQgdG8gUG9zdFNjcmlwdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2 DQo5LjIgIE90aGVyIE1JQiBPYmplY3RzIGFuZCBBdHRyaWJ1dGVzIE1hcHBl ZCB0byBQb3N0U2NyaXB0Li4uLi4uLi4uLi4uMTcNCjEwLjAgIE5FVFdBUkUg UFNFUlZFUi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4xNw0KMTAuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVk IHRvIFBTZXJ2ZXIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3DQox MC4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBQU2VydmVyLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcNCjEwLjMgIE90aGVyIE1JQiBP YmplY3RzIE1hcHBlZCB0byBQSkwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xNw0KMTAuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQg dG8gUFNlcnZlci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4DQoxMS4w ICBORVRXQVJFIE5QUklOVEVSIG9yIFJQUklOVEVSLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTgNCjEyLjAgIFNFUlZFUiBNRVNTQUdF IEJMT0NLIChTTUIpIFBST1RPQ09MLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xOA0KMTIuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFNN Qi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5DQoxMi4yICBq bUpvYkluZGV4IE1hcHBlZCB0byBTTUIuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTkNCjEyLjMgIE90aGVyIE1JQiBvYmplY3Rz IE1hcHBlZCB0byBTTUIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xOQ0KMTMuMCAgVFJBTlNQT1JUIElOREVQRU5ERU5UIFBSSU5URVIvU1lT VEVNIElOVEVSRkFDRSAoVElQL1NJKS4uLi4uLi4uLjE5DQoxMy4xICBqbUpv YlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gVElQL1NJLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTkNCjEzLjIgIGptSm9iSW5kZXggTWFwcGVkIHRv IFRJUC9TSS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4y MA0KMTMuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRvIFRJUC9TSS4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwDQoxMy40ICBUaGUgQXR0 cmlidXRlIEdyb3VwIE1hcHBlZCB0byBUSVAvU0kuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjANCjE0LjAgIFJFRkVSRU5DRVMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0K MTUuMCAgQVVUSE9SUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIxDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkJlcmdtYW4gICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFs ICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDJdDQwNCklOVEVSTkVULURS QUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAg ICAgICBGZWIgMiwgMTk5OA0KDQoNCg0KDQoxLjAgIElOVFJPRFVDVElPTg0K DQpUaGUgSm9iIE1vbml0b3JpbmcgTUlCIFtKb2JNSUJdIGlzIGludGVuZGVk IHRvIGJlIGltcGxlbWVudGVkIGluIGENCmRldmljZSBvciBzZXJ2ZXIgdGhh dCBzdXBwb3J0cyBhbnkgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2wuICBIb3dl dmVyLA0KdGhlIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhbmQgdGhlIG1ldGhv ZCBvZiBwcmVzZW50YXRpb24gdmFyaWVzDQpzaWduaWZpY2FudGx5IGJ5IGpv YiBzdWJtaXNzaW9uIHByb3RvY29sLiAgQSBjb21tb24gbWV0aG9kIG9mIG1h cHBpbmcNCmpvYiBzdWJtaXNzaW9uIGluZm9ybWF0aW9uIHRvIHRoZSBKb2Ig TW9uaXRvcmluZyBNSUIgaXMgZXNzZW50aWFsIGZvcg0KaW50ZXJvcGVyYWJp bGl0eSBvZiBKb2IgTUlCIGFnZW50cyBhbmQgbW9uaXRvcmluZyBhcHBsaWNh dGlvbnMuICBUaGlzDQpkb2N1bWVudCBkZWZpbmVzIHJlY29tbWVuZGVkIG1h cHBpbmdzIGZvciBtb3N0IHBvcHVsYXIgam9iIHN1Ym1pc3Npb24NCnByb3Rv Y29scyB0byBpbnN1cmUgdGhpcyBjb21wYXRpYmlsaXR5Lg0KDQpBbGwgbWFw cGluZ3MgYXJlIHVuaWRpcmVjdGlvbmFsIGZyb20gdGhlIGpvYiBzdWJtaXNz aW9uIHByb3RvY29sIHRvIHRoZQ0KTUlCLiAgSXQgaXMgYXNzdW1lZCB0aGF0 IHN1cHBvcnQgb2YgdGhlIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sIGluIHRo ZQ0KcHJpbnRlciBpbXBsaWVzIHRoYXQgdGhlIHJldmVyc2UgaW5mb3JtYXRp b24gZmxvdyBpcyBwcmVzZW50bHkgZGVmaW5lZA0KYW5kIGRvZXMgbm90IHJl cXVpcmUgaW50ZXJhY3Rpb24gZnJvbSB0aGUgTUlCLiAgVGhpcyBtYXBwaW5n IGlzIG5vdA0KZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFzIGl0IHNob3Vs ZCBiZSBvYnZpb3VzLg0KDQpUaGlzIGRvY3VtZW50IHJlZmVycyB0byBzeXN0 ZW0gY29uZmlndXJhdGlvbnMgdGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUNCkpv YiBNb25pdG9yaW5nIE1JQiBbSm9iTUlCXS4gIEZvciB0aG9zZSByZWFkZXJz IHRoYXQgYXJlIGZhbWlsaWFyIHdpdGgNCnRoZSBjb25maWd1cmF0aW9uIGRl c2NyaXB0aW9ucywgYSBzaG9ydCBzdW1tYXJ5IGFwcGVhcnMgaGVyZS4gIFBs ZWFzZQ0Kc2VlIHRoZSBKb2IgTUlCIGRvY3VtZW50IGZvciBmdXJ0aGVyIGRl dGFpbHMuDQoNCiAgIENvbmZpZ3VyYXRpb24gMTogIFRoaXMgaXMgYSBzaW1w bGUgcGVlci10by1wZWVyIHN5c3RlbSB3aGljaCBjb250YWlucw0KICAgICAg IG9ubHkgYSBjbGllbnQgYW5kIGEgcHJpbnRlci4gIFRoZSBKb2IgTUlCIGFn ZW50IGlzIHJlc2lkZW50IGluDQogICAgICAgdGhlIHByaW50ZXIuDQoNCiAg IENvbmZpZ3VyYXRpb24gMjogIFRoaXMgc3lzdGVtIGNvbnRhaW5zIGEgY2xp ZW50LCBzZXJ2ZXIsIGFuZCBhDQogICAgICAgcHJpbnRlci4gIFRoZSBKaWIg TUlCIGFnZW50IGlzIHJlc2lkZW50IGluIHRoZSBzZXJ2ZXIuDQoNCiAgIENv bmZpZ3VyYXRpb24gMzogIFRoaXMgc3lzdGVtLCBhcyBpbiBjb25maWd1cmF0 aW9uIDIsIGNvbnRhaW5zIGENCiAgICAgICBjbGllbnQsIHNlcnZlciwgYW5k IGEgcHJpbnRlci4gIEluIHRoaXMgY2FzZSB0aGUgSm9iIE1JQiBhZ2VudCBp cw0KICAgICAgIGltcGxlbWVudGVkIHdpdGhpbiB0aGUgcHJpbnRlci4NCg0K VGhlIG1vc3QgaW1wb3J0YW50IG9iamVjdCB0byBiZSBtYXBwZWQgaXMgam1K b2JTdWJtaXNzaW9uSUQsIHNpbmNlIHRoaXMNCmlzIGEgbWV0aG9kIGZvciB0 aGUgdXNlciBvciBjbGllbnQgdG8gZGV0ZXJtaW5lIHRoZSBqbUpvYkluZGV4 IGZvciBhDQpzdWJtaXR0ZWQgam9iLiAgVGhlcmVmb3JlLCBqbUpvYlN1Ym1p c3Npb25JRCBpcyBzcGVjaWZpZWQgZm9yIGFsbCBqb2INCnN1Ym1pc3Npb24g cHJvdG9jb2xzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSByZW1h aW5pbmcgb2JqZWN0cw0KbWFwcGVkIGluY2x1ZGUgb25seSB0aG9zZSBpdGVt cyB0aGF0IGhhdmUgdGhlIGVxdWl2YWxlbnQgaW5mb3JtYXRpb24NCnByZXNl bnRlZCB0byB0aGUgcHJpbnRlciBieSB0aGUgam9iIHN1Ym1pc3Npb24gcHJv dG9jb2wuDQoNCldoaWxlIHRoaXMgZG9jdW1lbnQgcGxhY2VzIGEgc3Ryb25n IGVtcGhhc2lzIG9uIGptSm9iU3VibWlzc2lvbklEDQptYXBwaW5nIHRvIG9i dGFpbiBqbUpvYkluZGV4LCB0aGUgcHJlZmVycmVkIG1ldGhvZCBpcyB0aHJv dWdoIHRoZSB1c2Ugb2YNCmEgYmktZGlyZWN0aW9uYWwgcHJvdG9jb2wgdGhh dCByZXR1cm5zIHRoZSB2YWx1ZSBvZiBqbUpvYkluZGV4IHRvIHRoZQ0KY2xp ZW50LCBzdWNoIGFzIElQUC4gIFdoZW4gYSBiaS1kaXJlY3Rpb25hbCBwcm90 b2NvbCB0aGF0IHJldHVybnMNCmptSm9iSW5kZXggaXMgaW4gdXNlLCB0aGUg am1Kb2JTdWJtaXNzaW9uSUQgb2JqZWN0IGhhcyBubyB2YWx1ZSB0byB0aGUN CmNsaWVudC4gIFdoZW4gdGhlIGptSm9iSW5kZXggY2Fubm90IGJlIHJldHVy bmVkLCB0aGUgdXNlIG9mIGEgY2xpZW50DQpkZWZpbmVkIGptSm9iU3VibWlz c2lvbklEIGlzIHByZWZlcnJlZCBvdmVyIGFuIGFnZW50IGRlcml2ZWQgdmFs dWUuICBUaGUNCmNsaWVudCBkZWZpbmVkIHZlcnNpb24gYWxsb3dzIGZvciBy ZXRyaWV2YWwgb2Ygam1Kb2JJbmRleCB1c2luZyBhIHNpbmdsZQ0KU05NUCBH ZXQgb3BlcmF0aW9uLCBzaW5jZSBqbUpvYlN1Ym1pc3Npb25JRCBpcyB0aGUg aW5kZXggaW50byB0aGUNCmptSm9iSURUYWJsZS4gIEFuIGFnZW50IGRlcml2 ZWQgdmFsdWUgd2lsbCByZXF1aXJlIGEgc2VhcmNoIHRocm91Z2gNCm11bHRp cGxlIGVudHJpZXMgaW4gdGhlIGptSm9iSURUYWJsZS4NCg0KDQoNCg0KQmVy Z21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAg ICAgICAgICAgICAgICAgW3BhZ2UgM10NDA0KSU5URVJORVQtRFJBRlQgICAg ICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZl YiAyLCAxOTk4DQoNCg0KDQoNClRoZSBtYWpvcml0eSBvZiB0aGUgcHJvdG9j b2xzIG1hcHBlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBvcmllbnRlZA0KdG93 YXJkcyBuZXR3b3JrIGpvYiBzdWJtaXNzaW9uLiAgSG93ZXZlciwgdGhlIEpv YiBNb25pdG9yaW5nIE1JQiBpcyBhbHNvDQppbnRlbmRlZCB0byBtb25pdG9y IHByaW50IGpvYnMgcmVjZWl2ZWQgZnJvbSBvdGhlciB0aGFuIG5ldHdvcmsg cG9ydHMsDQpzdWNoIGFzIHBhcmFsbGVsIGFuZCBzZXJpYWwgcG9ydHMuICBT b21lIG9mIHRoZSBqb2Igc3VibWlzc2lvbiBwcm90b2NvbHMNCmluY2x1ZGVk IHRoYXQgYXJlIHVzZWQgd2l0aCBub24tbmV0d29ya2VkIHBvcnRzIGFyZSBQ SkwsIFBvc3RTY3JpcHQsIGFuZA0KVElQL1NJLiAgSW4gYWRkaXRpb24sIHRo ZSBKb2IgTW9uaXRvcmluZyBNSUIgY2FuIGJlIHVzZWQgd2l0aCBwcmludCBq b2JzDQp0aGF0IGFyZSBpbnRlcm5hbGx5IGdlbmVyYXRlZCwgc3VjaCBhcyBz ZWxmIHRlc3QgcGFnZXMuICBJbiB0aGlzIGxhdHRlcg0KY2FzZSwgbm8gbWFw cGluZyBpcyByZXF1aXJlZCBzaW5jZSBhbGwgam9iIHN1Ym1pc3Npb24gcHJv dG9jb2xzIGFyZQ0KYnlwYXNzZWQuDQoNCg0KDQoyLjAgIExJTkUgUFJJTlRF UiBEQUVNT04gKExQUi9MUEQpIFBST1RPQ09MDQoNClRoZSBMUFIvTFBEIHBy aW50aW5nIHByb3RvY29sIFtMUERdIGlzIHVzZWQgd2l0aCBCU0QgVU5JWCBz eXN0ZW1zIGluIHRoZQ0KY2xpZW50LXNlcnZlci1wcmludGVyIGNvbmZpZ3Vy YXRpb24uICBVc2FnZSBvZiB0aGUgSm9iIE1vbml0b3JpbmcgTUlCDQp3aXRo IExQUi9MUEQgd2lsbCBtb3N0IGxpa2VseSBjb25mb3JtIHRvIENvbmZpZ3Vy YXRpb24gMywgd2hlcmUgdGhlDQptb25pdG9yIGFwcGxpY2F0aW9uIG9yIHRo ZSBzZXJ2ZXIgdXNlcyBTTk1QIHRvIG9idGFpbiBqb2IgaW5mb3JtYXRpb24N CmZyb20gdGhlIHByaW50ZXIuICBUaGUgY2xpZW50IGNvbW11bmljYXRlcyB3 aXRoIHRoZSBVTklYIHNlcnZlciB1c2luZw0KdGhlIGV4aXN0aW5nIExQRCBw cm90b2NvbCB0byBvYnRhaW4gam9iIGluZm9ybWF0aW9uLg0KDQpUaGUgTFBS L0xQRCBwcm90b2NvbCBpcyBhbHNvIHVzZWQgaW4gdGhlIFdpbmRvd3MgZW52 aXJvbm1lbnQgdG8NCmltcGxlbWVudCBwZWVyLXRvLXBlZXIgcHJpbnRpbmcs IGFzIHNob3duIGluIGNvbmZpZ3VyYXRpb24gMS4gIEluIHRoaXMNCmNhc2Us IFNOTVAgaXMgdXNlZCBieSB0aGUgY2xpZW50IGFuZC9vciB0aGUgbW9uaXRv ciBhcHBsaWNhdGlvbiB0bw0Kb2J0YWluIHRoZSBqb2IgaW5mb3JtYXRpb24u DQoNCk9uZSBvZiB0aGUgbWFqb3IgcHJvYmxlbXMgb2YgTFBSL0xQRCBpcyB0 aGUgbGFyZ2UgbnVtYmVyIG9mIHZlbmRvcg0KdW5pcXVlIGV4dGVuc2lvbnMg Y3VycmVudGx5IHVzZWQgd2l0aCB0aGUgcHJvdG9jb2wgYW5kIHRoZSByZXN1 bHRpbmcNCmNvbXBhdGliaWxpdHkgaXNzdWVzIGJldHdlZW4gYXZhaWxhYmxl IGltcGxlbWVudGF0aW9ucy4gIFRvIGF2b2lkIHRoZXNlDQppc3N1ZXMsIHRo aXMgbWFwcGluZyBvZiBMUFIvTFBEIGlzIHJlc3RyaWN0ZWQgdG8gdGhlIHBy b3RvY29sIGFzIGRlZmluZWQNCmJ5IFJGQyAxMTc5Lg0KDQpUaGUgTFBSL0xQ RCBwcm90b2NvbCB0cmFuc2ZlcnMgcHJpbnQgam9iIGRhdGEgYW5kIGNvbnRy b2wgaW5mb3JtYXRpb24gaW4NCnNlcGFyYXRlIGZpbGVzLCBrbm93biBhcyB0 aGUgRGF0YSBGaWxlIGFuZCBDb250cm9sIEZpbGUsIHJlc3BlY3RpdmVseS4N Ck1vc3Qgb2YgdGhlIGluZm9ybWF0aW9uIGNvbmNlcm5pbmcgdGhlIHByaW50 IGpvYiBpcyBjb250YWluZWQgaW4gdGhlDQpDb250cm9sIEZpbGUuICBJbiBt YW55IExQRCBpbXBsZW1lbnRhdGlvbnMsIHRoZSBDb250cm9sIEZpbGUgaXMN CnRyYW5zZmVycmVkIGZvbGxvd2luZyB0aGUgRGF0YSBGaWxlLiAgVGh1cyBt dWNoIG9mIHRoZSBpbmZvcm1hdGlvbg0KY29uY2VybmluZyB0aGUgam9iIG1h eSBub3QgYmUgYXZhaWxhYmxlIHVudGlsIHRoZSBjb21wbGV0aW9uIG9mIHRo ZSBkYXRhDQp0cmFuc21pc3Npb24uDQoNCg0KMi4xICBqbUpvYlN1Ym1pc3Np b25JRCBNYXBwZWQgdG8gTFBSL0xQRA0KDQpUaGUgTFBSL0xQRCBSZWNlaXZl IERhdGEgRmlsZSBjb21tYW5kIGNvbnRhaW5zIGEgcGFyYW1ldGVyIHdoaWNo IGRlZmluZXMNCnRoZSBuYW1lIG9mIHRoZSBkYXRhIGZpbGUuICBUaGlzIG5h bWUgZmllbGQgaXMgc3RydWN0dXJlZCBhcyBmb2xsb3dzOg0KDQogICAgICAg IGRmYVhYWDxob3N0LW5hbWU+ICBvciAgZGFYWFhYPGhvc3QtbmFtZT4NCg0K V2hlcmUgWFhYIG9yIFhYWFggaXMgdGhlIG51bWVyaWMgam9iIG51bWJlciBh c3NpZ25lZCBieSB0aGUgTFBSL0xQRA0KY2xpZW50IHN1Ym1pdHRpbmcgdGhl IHByaW50IGpvYi4gIFRoZSByZWNvbW1lbmRlZCBtYXBwaW5nIG9mIHRoaXMg bmFtZQ0KZmllbGQgdG8gam1Kb2JTdWJtaXNzaW9uSUQgaXM6DQoNCg0KDQoN CkJlcmdtYW4gICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAg ICAgICAgICAgICAgICAgICAgIFtwYWdlIDRdDQwNCklOVEVSTkVULURSQUZU ICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAg ICBGZWIgMiwgMTk5OA0KDQoNCg0KDQogIG9jdGV0IDE6ICAgJzknDQoNCiAg b2N0ZXRzIDItNDA6ICBDb250YWlucyB0aGUgPGhvc3QtbmFtZT4gcG9ydGlv biBvZiB0aGUgbmFtZSBmaWVsZC4gIElmDQogICAgICAgICAgICAgICAgdGhl IDxob3N0LW5hbWU+IHBvcnRpb24gaXMgbGVzcyB0aGFuIDQwIG9jdGV0cywg dGhlDQogICAgICAgICAgICAgICAgbGVmdC1tb3N0IGNoYXJhY3RlciBpbiB0 aGUgc3RyaW5nIHNoYWxsIGFwcGVhciBpbiBvY3RldA0KICAgICAgICAgICAg ICAgIHBvc2l0aW9uIDIuICBBbnkgdW51c2VkIHBvcnRpb24gb2YgdGhpcyBm aWVsZCBzaGFsbCBiZQ0KICAgICAgICAgICAgICAgIGZpbGxlZCB3aXRoIHNw YWNlcy4gIE90aGVyd2lzZSwgb25seSB0aGUgbGFzdCAzOSBieXRlcw0KICAg ICAgICAgICAgICAgIHNoYWxsIGJlIGluY2x1ZGVkLg0KDQogIG9jdGV0cyA0 MS00ODogICcwMDAwMFhYWCcgb3IgJzAwMDBYWFhYJywgd2hlcmUgWFhYIG9y IFhYWFggaXMgdGhlDQogICAgICAgICAgICAgICAgIGRlY2ltYWwgKEFTQ0lJ IGNvZGVkKSByZXByZXNlbnRhdGlvbiBvZiB0aGUgTFBSL0xQRA0KICAgICAg ICAgICAgICAgICBqb2IgbnVtYmVyLg0KDQoNCjIuMiAgam1Kb2JJbmRleCBN YXBwZWQgdG8gTFBSL0xQRA0KDQpUaGUgam9iIGluZGV4IChqbUpvYkluZGV4 KSBpcyBhc3NpZ25lZCBieSB0aGUgU05NUCBqb2IgbW9uaXRvcmluZyBhZ2Vu dA0KYW5kIGlzIGluZGVwZW5kZW50IG9mIHRoZSBYWFggKG9yIFhYWFgpIGlu ZGV4IGFzc2lnbmVkIGJ5IHRoZSBMUFIvTFBEDQpjbGllbnQuICBUaGlzIHdp bGwgYWxsb3cgdGhlIFNOTVAgYWdlbnQgdG8gdHJhY2sgam9icyByZWNlaXZl ZCBmcm9tDQptdWx0aXBsZSBzb3VyY2VzLg0KDQoNCjIuMyAgT3RoZXIgTUlC IE9iamVjdHMgTWFwcGVkIHRvIExQUi9MUEQNCg0KTUlCIE9iamVjdCAgICAg ICAgICAgICAgICAgICAgfCBMUFIvTFBEIFBhcmFtZXRlcg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0Kam1Kb2JLT2N0ZXRzUGVyQ29weVJlcXVlc3Rl ZCAgfCBOdW1iZXIgb2YgYnl0ZXMgYXMgZGVmaW5lZCBpbiB0aGUgRGF0YQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBGaWxlDQpqbUpvYk93 bmVyICAgICAgICAgICAgICAgICAgICB8IENvbnRyb2wgZmlsZSBjb21tYW5k IGNvZGUgPSBQIChVc2VyIElkKQ0KDQoNCjIuNCAgVGhlIEF0dHJpYnV0ZSBH cm91cCBNYXBwZWQgdG8gTFBEDQoNCk90aGVyIGF0dHJpYnV0ZXMgdGhhdCBh cmUgYXBwbGljYWJsZSwgYnV0IG5vdCBkZWZpbmVkIGluIHRoaXMgc2VjdGlv bg0Kc3VjaCBhcyBhdHRyaWJ1dGVzIHRoYXQgbWFwIHRvIGEgdmVuZG9yIHVu aXF1ZSBleHRlbnNpb24sIG1heSBhbHNvIGJlDQppbmNsdWRlZC4NCg0KTUlC IGF0dHJpYnV0ZSAgICAgICAgIHwgTFBSL0xQRCBpbmZvcm1hdGlvbiAgICAg ICAgICAgICB8IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0NCmpvYk5hbWUgICAgICAgICAgICAgICB8IE5hbWUgb2YgdGhlIGRhdGEg ZmlsZSAobm90ZSAxKSAgfCBPY3RldCBTdHJpbmcNCnF1ZXVlTmFtZVJlcXVl c3RlZCAgICB8IFF1ZXVlIG5hbWUgZnJvbSB0aGUgRGF0YSBGaWxlICAgfCBP Y3RldCBTdHJpbmcNCmZpbGVOYW1lICAgICAgICAgICAgICB8IFNvdXJjZSBG aWxlIE5hbWUgKG5vdGVzIDIsIDMpICAgfCBPY3RldCBTdHJpbmcNCmRvY3Vt ZW50TmFtZSAgICAgICAgICB8IERvY3VtZW50IHRpdGxlIChub3RlcyAyLCA0 KSAgICAgfCBPY3RldCBTdHJpbmcNCg0KIE5vdGVzOg0KIC0tLS0tLQ0KICAx LiBTZWUgc2VjdGlvbiAyLjEgKGptSm9iU3VibWlzc2lvbklEKS4NCiAgMi4g VGhlIGluZm9ybWF0aW9uIGlzIG9wdGlvbmFsIGluIHRoZSBDb250cm9sIEZp bGUuICBUaGUgYXR0cmlidXRlDQogICAgIHNob3VsZCBiZSBpbmNsdWRlZCBp ZiBwcmVzZW50IGluIHRoZSBDb250cm9sIEZpbGUuDQogIDMuIENvbnRyb2wg ZmlsZSBjb21tYW5kIGNvZGUgPSBOLg0KICA0LiBDb250cm9sIGZpbGUgY29t bWFuZCBjb2RlID0gSi4NCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgNV0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24g UHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAyLCAxOTk4DQoNCg0KDQoN Cg0KDQozLjAgIEFQUExFVEFMSyBQUk9UT0NPTA0KDQpBcHBsZVRhbGsgd2Fz IG9yaWdpbmFsbHkgZGV2ZWxvcGVkIGFzIGEgcGVlci10by1wZWVyIG5ldHdv cmsgcHJvdG9jb2wsDQphcyBkZXNjcmliZWQgaW4gY29uZmlndXJhdGlvbiAx LCBmb3IgdXNlIHdpdGggQXBwbGUgTWFjaW50b3NoIGNvbXB1dGVycy4NClRv ZGF5LCBwcmludCBzcG9vbGVycyBhcmUgYWxzbyBhdmFpbGFibGUgZm9yIHVz ZSB3aXRoIE1hY2ludG9zaCBjb21wdXRlcg0KbmV0d29ya3MgdGhhdCBjb25m b3JtIHRvIGNvbmZpZ3VyYXRpb25zIDIvMy4gIEluIGFkZGl0aW9uLCBwcmlu dGluZyB3aXRoDQp0aGUgQXBwbGVUYWxrIHByb3RvY29sIGlzIHN1cHBvcnRl ZCBmcm9tIGJvdGggV2luZG93cyBOVCBzZXJ2ZXJzIGFuZA0KTm92ZWxsIHNl cnZlcnMgYWxzbyBwZXIgY29uZmlndXJhdGlvbnMgMi8zLg0KDQpUaGUgQXBw bGVUYWxrIHByb3RvY29sIHByb3ZpZGVzIHZlcnkgbGl0dGxlIGluZm9ybWF0 aW9uIHRoYXQgY2FuIGJlIHVzZWQNCndpdGggdGhlIEpvYiBNb25pdG9yaW5n IE1JQi4gIFRoZSBNYWNpbnRvc2ggcHJpbnQgZHJpdmVycyBhcmUgYWJsZSB0 bw0KcHJvdmlkZSBpbmZvcm1hdGlvbiBjb25jZXJuaW5nIHRoZSB1c2VyIGFu ZCBkb2N1bWVudCBuYW1lIGJ1dCBpbWJlZCB0aGlzDQppbmZvcm1hdGlvbiBp biB0aGUgUERMLCB3aGljaCBpcyB0eXBpY2FsbHkgUG9zdFNjcmlwdC4gIFRo ZSBwcmVmZXJyZWQNCmptSm9iU3VibWlzc2lvbklEIGlzIGNvbnN0cnVjdGVk IGZyb20gdGhlIGluZm9ybWF0aW9uIGluIHRoZSBQb3N0U2NyaXB0DQpmaWxl LCBhcyBkZWZpbmVkIGluIHNlY3Rpb24gOS4wLg0KDQoNCjMuMSAgam1Kb2JT dWJtaXNzaW9uSUQgTWFwcGVkIHRvIEFwcGxlVGFsaw0KDQpBbiBhbHRlcm5h dGl2ZSBqbUpvYlN1Ym1pc3Npb25JRCBtYXkgYmUgY29uc3RydWN0ZWQgZnJv bSB0aGUgQ29ubmVjdGlvbg0KSWRlbnRpZmllciBjb250YWluZWQgaW4gdGhl IEFwcGxlVGFsayBQcmludGVyIEFjY2VzcyBQcm90b2NvbCAoUEFQKQ0KaGVh ZGVyLiAgU2luY2UgdGhlIENvbm5lY3Rpb24gSWQgaXMgbm90IHJlYWRpbHkg YXZhaWxhYmxlIGluIGFueSBvZiB0aGUNCmRlZmluZWQgQXBwbGVUYWxrIGlt cGxlbWVudGF0aW9ucywgdGhpcyBhcHByb2FjaCBtYXkgYmUgb2YgbGl0dGxl DQp1dGlsaXR5Lg0KDQogIG9jdGV0IDE6ICAgJ0EnDQoNCiAgb2N0ZXRzIDIt NDA6ICBDb250YWlucyB0aGUgQXBwbGVUYWxrIHByaW50ZXIgbmFtZSwgd2l0 aCB0aGUgZmlyc3QNCiAgICAgICAgICAgICAgICBjaGFyYWN0ZXIgb2YgdGhl IG5hbWUgaW4gb2N0ZXQgMi4gIEFwcGxlVGFsayBwcmludGVyDQogICAgICAg ICAgICAgICAgbmFtZXMgYXJlIGEgbWF4aW11bSBvZiAzMSBjaGFyYWN0ZXJz LiAgQW55IHVudXNlZA0KICAgICAgICAgICAgICAgIHBvcnRpb24gb2YgdGhp cyBmaWVsZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuDQoNCiAgb2N0 ZXRzIDQxLTQ4OiAgJzAwMDAwWFhYJywgd2hlcmUgJ1hYWCcgaXMgdGhlIGRl Y2ltYWwgKEFTQ0lJIGNvZGVkKQ0KICAgICAgICAgICAgICAgICByZXByZXNl bnRhdGlvbiBvZiB0aGUgQ29ubmVjdGlvbiBJZC4NCg0KDQozLjIgIE90aGVy IEFwcGxlVGFsayBNYXBwaW5ncw0KDQpObyBvdGhlciBKb2IgTUlCIG9iamVj dHMgb3IgcGFyYW1ldGVycyBjYW4gYmUgZGVyaXZlZCBmcm9tIGluZm9ybWF0 aW9uDQphdmFpbGFibGUgaW4gdGhlIEFwcGxlVGFsayBoZWFkZXJzDQoNCg0K DQo0LjAgIElOVEVSTkVUIFBSSU5USU5HIFBST1RPQ09MIChJUFApDQoNClRo ZSBJbnRlcm5ldCBQcmludGluZyBQcm90b2NvbCBbSVBQXSBzdXBwb3J0cyBw cmludGluZyB1c2luZyBhbnkgb25lIG9mDQp0aGUgdGhyZWUgcG9zc2libGUg Y29uZmlndXJhdGlvbnMuICBGb3IgY29uZmlndXJhdGlvbiAyLCB0aGUgbWFw cGluZw0KZGVmaW5lZCBoZXJlaW4gaXMgcGVyZm9ybWVkIG9uIGFuIGFnZW50 IHdpdGhpbiB0aGUgc2VydmVyLiAgT3RoZXJ3aXNlLA0KdGhlIG1hcHBpbmcg aXMgcGVyZm9ybWVkIG9uIGFuIGFnZW50IHdpdGhpbiB0aGUgcHJpbnRlci4N Cg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0 aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgNl0NDA0KSU5URVJO RVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGlu ZyAgICAgICAgIEZlYiAyLCAxOTk4DQoNCg0KDQoNCg0KNC4xICBqbUpvYlN1 Ym1pc3Npb25JRCBNYXBwZWQgdG8gSVBQDQoNCklQUCBjb250YWlucyBhIHJp Y2ggc2V0IG9mIHBhcmFtZXRlcnMgd2hpY2ggYWxsb3cgc2V2ZXJhbCBtZXRo b2RzIG9mDQpjcmVhdGluZyB0aGUgam1Kb2JTdWJtaXNzaW9uSUQgb2JqZWN0 LiAgVG8gcHJldmVudCBpbnRlcm9wZXJhYmlsaXR5DQpwcm9ibGVtcywgdGhl IHByZWZlcnJlZCBtZXRob2QgaXMgdG8gdXNlIHRoZSBJUFAgam9iLXVyaSBh dHRyaWJ1dGUgYXMNCmZvbGxvd3M6DQoNCiAgb2N0ZXQgMTogICAnNCcNCg0K ICBvY3RldHMgMi00MDogIENvbnRhaW5zIHRoZSBJUFAgam9iLXVyaSBqb2Ig ZGVzY3JpcHRpb24gYXR0cmlidXRlDQogICAgICAgICAgICAgICAgZ2VuZXJh dGVkIGJ5IHRoZSBwcmludGVyLiAgKFRoZSBqb2ItdXJpIGlzIHJldHVybmVk IHRvDQogICAgICAgICAgICAgICAgdGhlIGNsaWVudCBieSBJUFAuKSAgSWYg dGhlIGpvYi11cmkgaXMgbGVzcyB0aGFuIDQwDQogICAgICAgICAgICAgICAg b2N0ZXRzLCB0aGUgbGVmdC1tb3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5n IHNoYWxsDQogICAgICAgICAgICAgICAgYXBwZWFyIGluIG9jdGV0IHBvc2l0 aW9uIDIuICBBbnkgdW51c2VkIHBvcnRpb24gb2YgdGhpcw0KICAgICAgICAg ICAgICAgIGZpZWxkIHNoYWxsIGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4gIE90 aGVyd2lzZSwgb25seSB0aGUNCiAgICAgICAgICAgICAgICBsYXN0IDM5IGJ5 dGVzIHNoYWxsIGJlIGluY2x1ZGVkLg0KDQogIG9jdGV0cyA0MS00ODogIENv bnRhaW5zIHRoZSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRp b24gb2YNCiAgICAgICAgICAgICAgICAgdGhlIGpvYi1pZCBqb2IgZGVzY3Jp cHRpb24gYXR0cmlidXRlLiAgTGVhZGluZyB6ZXJvcw0KICAgICAgICAgICAg ICAgICBzaGFsbCBiZSBpbnNlcnRlZCB0byBmaWxsIHRoZSBlbnRpcmUgOCBv Y3RldCBmaWVsZC4NCg0KDQo0LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIElQ UA0KDQpUaGUgam9iIGluZGV4IChqbUpvYkluZGV4KSBhc3NpZ25lZCBieSB0 aGUgU05NUCBqb2IgbW9uaXRvcmluZyBhZ2VudCBpcw0KcmV0dXJuZWQgdG8g dGhlIGNsaWVudCBieSBJUFAgYXMgdGhlIGpvYi1pZCBqb2IgZGVzY3JpcHRp b24gYXR0cmlidXRlLg0KKFNpbmNlIElQUCBkb2VzIG5vdCByZXF1aXJlIGNv bnNlY3V0aXZlbHkgZ2VuZXJhdGVkIGpvYi1pZHMsIHRoZSBhZ2VudA0KbWF5 IHJlY2VpdmUgam9icyBmcm9tIG11bHRpcGxlIGNsaWVudHMgYW5kIGNhbiBh c3NpZ24gam1Kb2JJbmRleCBpbiBhbg0KYXNjZW5kaW5nIHNlcXVlbmNlIGlu ZGVwZW5kZW50IG9mIHRoZSBzdWJtaXR0aW5nIGpvYiBjbGllbnQuKSAgVGhl IElQUA0Kam9iLWlkIG11c3QgYmUgcmVzdHJpY3RlZCB0byB0aGUgcmFuZ2Ug b2YgMSB0byA5OSw5OTksOTk5IChkZWNpbWFsKSB0bw0KYWxsb3cgdGhlIHZh bHVlIHRvIGJlIHByb3Blcmx5IHJlcHJlc2VudGVkIGluIGptSm9iU3VibWlz c2lvbklELg0KDQoNCjQuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRv IElQUA0KDQpNSUIgT2JqZWN0ICAgICAgICAgICAgICAgICAgICAgICB8IElQ UCBKb2IgYXR0cmlidXRlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpt Sm9iU3RhdGUgICAgICAgICAgICAgICAgICAgICAgIHwgam9iLXN0YXRlDQpq bUpvYlN0YXRlUmVhc29uczEgICAgICAgICAgICAgICB8IGpvYi1zdGF0ZS1y ZWFzb25zIChub3RlIDEpDQpqbU51bWJlck9mSW50ZXJ2ZW5pbmdKb2JzICAg ICAgICB8IG51bWJlci1vZi1pbnRlcnZlbmluZy1qb2JzDQpqbUpvYktPY3Rl dHNQZXJDb3B5UmVxdWVzdGVkICAgICB8IGpvYi1rLW9jdGV0cw0Kam1Kb2JL T2N0ZXRzUHJvY2Vzc2VkICAgICAgICAgICAgfCBqb2Itay1vY3RldHMtcHJv Y2Vzc2VkDQpqbUpvYkltcHJlc3Npb25zUGVyQ29weVJlcXVlc3RlZCB8IGpv Yi1pbXByZXNzaW9ucw0Kam1Kb2JJbXByZXNzaW9uc0NvbXBsZXRlZCAgICAg ICAgfCBqb2ItaW1wcmVzc2lvbnMtY29tcGxldGVkDQpqbUpvYk93bmVyICAg ICAgICAgICAgICAgICAgICAgICB8IGpvYi1vcmlnaW5hdGluZy11c2VyLW5h bWUNCg0KIE5vdGVzOg0KIC0tLS0tLQ0KICAxLiBqbUpvYlN0YXRlUmVhc29u czEgaXMgYSBiaXQgbWFwIGRlc2NyaWJlZCBpbiBvbmUgb2JqZWN0IGFuZCB0 aHJlZQ0KICAgICBhdHRyaWJ1dGVzLiAgVGhlIElQUCBjb25kaXRpb24gbWF5 IGNoYW5nZSBvbmUgb3IgbW9yZSBvZiB0aGUgYml0cw0KICAgICBpbiBvbmUg b3IgbW9yZSBvZiB0aGVzZSBKb2IgTUlCIGl0ZW1zLg0KDQoNCg0KQmVyZ21h biAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAg ICAgICAgICAgICAgW3BhZ2UgN10NDA0KSU5URVJORVQtRFJBRlQgICAgICAg Sm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAy LCAxOTk4DQoNCg0KDQoNCg0KDQo0LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAg TWFwcGVkIHRvIElQUA0KDQpUaGUgZm9sbG93aW5nIG1hcHBpbmdzIGFyZSBy ZXF1aXJlZCBpZiB0aGUgbGlzdGVkIElQUCBqb2IgdGVtcGxhdGUNCmF0dHJp YnV0ZSBpcyBwcm92aWRlZC4NCg0KTUlCIGF0dHJpYnV0ZSAgICAgICAgICAg ICAgfCBJUFAgam9iIGF0dHJpYnV0ZSAgICAgICAgICAgIHwgRGF0YSB0eXBl DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0NCmpvYlN0YXRlUmVhc29u c04gICAgICAgICAgIHwgam9iLXN0YXRlLXJlYXNvbnMgKG5vdGUgMykgICB8 IEludGVnZXINCmpvYkNvZGVkQ2hhclNldCAgICAgICAgICAgIHwgYXR0cmli dXRlcy1jaGFyc2V0IChub3RlIDEpICB8IE9jdGV0IFN0cmluZw0Kam9iTmF0 dXJhbExhbmd1YWdlVGFnICAgICAgfCBhdHRyaWJ1dGVzLW5hdHVyYWwtbGFu Z3VhZ2UgIHwgT2N0ZXQgU3RyaW5nDQpqb2JVUkkgICAgICAgICAgICAgICAg ICAgICB8IGpvYi11cmkgICAgICAgICAgICAgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCmpvYk5hbWUgICAgICAgICAgICAgICAgICAgIHwgam9iLW5hbWUg ICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KcGh5c2ljYWxE ZXZpY2UgICAgICAgICAgICAgfCBvdXRwdXQtZGV2aWNlLWFzc2lnbmVkICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpudW1iZXJPZkRvY3VtZW50cyAgICAgICAg ICB8IG51bWJlci1vZi1kb2N1bWVudHMgICAgICAgICAgfCBJbnRlZ2VyDQpq b2JQcmlvcml0eSAgICAgICAgICAgICAgICB8IGpvYi1wcmlvcml0eSAgICAg ICAgICAgICAgICAgfCBJbnRlZ2VyDQpqb2JIb2xkVW50aWwgICAgICAgICAg ICAgICB8IGpvYi1ob2xkLXVudGlsICAgICAgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCnNpZGVzICAgICAgICAgICAgICAgICAgICAgIHwgc2lkZXMgKG5v dGUgMikgICAgICAgICAgICAgICB8IEludGVnZXINCmZpbmlzaGluZyAgICAg ICAgICAgICAgICAgIHwgZmluaXNoaW5ncyAgICAgICAgICAgICAgICAgICB8 IEludGVnZXINCnByaW50UXVhbGl0eVJlcXVlc3RlZCAgICAgIHwgcHJpbnQt cXVhbGl0eSAgICAgICAgICAgICAgICB8IEludGVnZXINCnByaW50ZXJSZXNv bHV0aW9uUmVxdWVzdGVkIHwgcHJpbnRlci1yZXNvbHV0aW9uICAgICAgICAg ICB8IEludGVnZXINCmpvYkNvcGllc1JlcXVlc3RlZCAgICAgICAgIHwgY29w aWVzIChub3RlIDQpICAgICAgICAgICAgICB8IEludGVnZXINCmRvY3VtZW50 Q29waWVzUmVxdWVzdGVkICAgIHwgY29waWVzIChub3RlIDQpICAgICAgICAg ICAgICB8IEludGVnZXINCmpvYkNvbGxhdGlvblR5cGUgICAgICAgICAgIHwg bXVsdGlwbGUtZG9jdW1lbnQtaGFuZGxpbmcgICB8IEludGVnZXINCnNoZWV0 c1JlcXVlc3RlZCAgICAgICAgICAgIHwgam9iLW1lZGlhLXNoZWV0cyAgICAg ICAgICAgICB8IEludGVnZXINCnNoZWV0c0NvbXBsZXRlZCAgICAgICAgICAg IHwgam9iLW1lZGlhLXNoZWV0cy1jb21wbGV0ZWQgICB8IEludGVnZXINCm1l ZGl1bVJlcXVlc3RlZCAgICAgICAgICAgIHwgbWVkaWEgICAgICAgICAgICAg ICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iU3VibWlzc2lvblRpbWUg ICAgICAgICAgfCB0aW1lLWF0LXN1Ym1pc3Npb24gICAgICAgICAgIHwgSW50 ZWdlcg0Kam9iU3RhcnRlZFByb2Nlc3NpbmdUaW1lICAgfCB0aW1lLWF0LXBy b2Nlc3NpbmcgICAgICAgICAgIHwgSW50ZWdlcg0Kam9iQ29tcGxldGlvblRp bWUgICAgICAgICAgfCB0aW1lLWF0LWNvbXBsZXRlZCAgICAgICAgICAgIHwg SW50ZWdlcg0KDQogTm90ZXM6DQogLS0tLS0tDQogIDEuIGpvYkNvZGVkQ2hh clNldCBpcyBhbiBlbnVtIGZyb20gdGhlIElBTkEgcmVnaXN0cnkgd2hpY2gg aXMgYWxzbw0KICAgICB1c2VkIGluIHRoZSBQcmludGVyIE1JQi4gIFRoZSBJ UFAgYXR0cmlidXRlcy1jaGFyc2V0IGlzIHRoZSBuYW1lDQogICAgIChNSU1F IHByZWZlcnJlZCBuYW1lKSBvZiB0aGUgY2hhcmFjdGVyIHNldC4NCiAgMi4g VGhlIEpvYiBNSUIgc2lkZXMgYXR0cmlidXRlIHVzZXMgdGhlIGludGVnZXIg dmFsdWVzICIxIiBhbmQgIjIiLg0KICAgICBUaGUgSVBQIHNpZGVzIGF0dHJp YnV0ZSB1c2VzIHRocmVlIGtleXdvcmRzLg0KICAzLiBqb2JTdGF0ZVJlYXNv bnNOIGlzIGEgYml0IG1hcCBkZXNjcmliZWQgaW4gb25lIG9iamVjdCBhbmQg dGhyZWUNCiAgICAgYXR0cmlidXRlcy4gIFRoZSBJUFAgY29uZGl0aW9uIG1h eSBjaGFuZ2Ugb25lIG9yIG1vcmUgb2YgdGhlIGJpdHMNCiAgICAgaW4gb25l IG9yIG1vcmUgb2YgdGhlc2UgSm9iIE1JQiBpdGVtcy4NCiAgNC4gVGhlIElQ UCAiY29waWVzIiBhdHRyaWJ1dGUgbWFwcyB0byB0aGUgSm9iIE1JQjoNCiAg ICAgKDEpIGpvYkNvcGllc1JlcXVlc3RlZCB3aGVuIHRoZSBqb2IgaGFzIG9u bHkgb25lIGRvY3VtZW50IE9SDQogICAgICAgICBJUFAgIm11bHRpcGxlLWRv Y3VtZW50LWhhbmRsaW5nIiBpcyAnc2luZ2xlLXZhbHVlZCcNCiAgICAgKDIp IGRvY3VtZW50Q29waWVzUmVxdWVzdGVkLCBpbiB3aGljaCBjYXNlIHRoZSBN SUIgdmFsdWUgaXMgdGhlDQogICAgICAgICB0b3RhbCBudW1iZXIgb2YgZG9j dW1lbnQgY29waWVzIHRoYXQgdGhlIGpvYiB3aWxsIHByb2R1Y2UgYXMgYQ0K ICAgICAgICAgd2hvbGUuDQoNCg0KDQoNCg0KDQoNCkJlcmdtYW4gICAgICAg ICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAg ICAgIFtwYWdlIDhdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJt aXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMiwgMTk5OA0K DQoNCg0KDQo1LjAgIElOVEVMTElHRU5UIFBSSU5URVIgREFUQSBTVFJFQU0g KElQRFMpDQoNClRoZSBJUERTIGRhdGFzdHJlYW0gZmFjaWxpdGF0ZXMgYSBj bG9zZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgcHJpbnQNCnN1cGVydmlz b3IgKFByaW50IFNlcnZpY2VzIEZhY2lsaXR5IC0gUFNGKSBhbmQgdGhlIHBy aW50ZXIuIFRoZXJlIGFyZQ0KUFNGIGFwcGxpY2F0aW9ucyBmb3IgVW5peCwg V2luZG93cywgT1MvMiwgT1MvNDAwIGFuZCBob3N0IG9wZXJhdGluZw0Kc3lz dGVtcyBzdWNoIGFzIFZNLCBNVlMgYW5kIFZTRS4gVG9nZXRoZXIsIFBTRiBh bmQgSVBEUyByZXByZXNlbnQgYQ0KY29tcGxldGUsIG1hdHVyZSBhbmQgcm9i dXN0IGpvYiBtYW5hZ2VtZW50IGZyYW1ld29yayB3aGljaCBpbmNsdWRlcyBm b250DQphbmQgcmVzb3VyY2UgbWFuYWdlbWVudCwgcGFnZSBwcm9ncmVzcyB0 cmFja2luZywgam9iIGNhbmNlbGxhdGlvbiwNCmNvbXBsZXRlIGVycm9yIHJl Y292ZXJ5IGFuZCBlbmQtdXNlciBub3RpZmljYXRpb24uIEJlY2F1c2UgUFNG IGFuZCB0aGUNCnByaW50ZXIgY29ycmVzcG9uZCB2aWEgdGhlIHVzZSBvZiBs b2NhbGx5IGFzc2lnbmVkIElEknMsIHRoZXJlIGlzIGENCmxpbWl0ZWQgYW1v dW50IG9mIGNsZWFyIHRleHQgaW5mb3JtYXRpb24gcHJvdmlkZWQgZHVyaW5n IHN1Ym1pc3Npb24gZm9yDQp1c2UgYnkgdGhlIEpvYiBNSUIuDQoNCg0KNS4x ICBqbUpvYlN1Ym1pc3Npb25JZCBNYXBwZWQgdG8gSVBEUw0KDQpGb3IgSVBE UyBvbiB0aGUgTVZTIG9yIFZTRSBwbGF0Zm9ybToNCg0KICBvY3RldCAxOiAg ICdFJw0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgYnl0ZXMgMi0yNyBv ZiB0aGUgWE9IIERlZmluZSBHcm91cCBCb3VuZGFyeQ0KICAgICAgICAgICAg ICAgIEdyb3VwIElEIHRyaXBsZXQuIE9jdGV0IHBvc2l0aW9uIDIgbXVzdCBj YXJyeSB0aGUgdmFsdWUNCiAgICAgICAgICAgICAgICB4kjAxki5CeXRlcyAy OC00MCBtdXN0IGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4NCg0KICBvY3RldHMg NDEtNDg6ICBDb250YWlucyBhIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXBy ZXNlbnRhdGlvbiBvZiB0aGUNCiAgICAgICAgICAgICAgICAgam1Kb2JJbmRl eCBhc3NpZ25lZCBieSB0aGUgYWdlbnQuICBMZWFkaW5nIHplcm9zIHNoYWxs DQogICAgICAgICAgICAgICAgIGJlIGluc2VydGVkIHRvIGZpbGwgdGhlIGVu dGlyZSA4IG9jdGV0IGZpZWxkLg0KDQoNCkZvciBJUERTIG9uIHRoZSBWTSBw bGF0Zm9ybToNCg0KICBvY3RldCAxOiAgICdGJw0KDQogIG9jdGV0cyAyLTQw OiAgQ29udGFpbnMgYnl0ZXMgMi0zMSBvZiB0aGUgWE9IIERlZmluZSBHcm91 cCBCb3VuZGFyeQ0KICAgICAgICAgICAgICAgIEdyb3VwIElEIHRyaXBsZXQu IE9jdGV0IHBvc2l0aW9uIDIgbXVzdCBjYXJyeSB0aGUgdmFsdWUNCiAgICAg ICAgICAgICAgICB4kjAyki5CeXRlcyAzMi00MCBtdXN0IGJlIGZpbGxlZCB3 aXRoIHNwYWNlcy4NCg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlucyBhIGRl Y2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRhdGlvbiBvZiB0aGUNCiAg ICAgICAgICAgICAgICAgam1Kb2JJbmRleCBhc3NpZ25lZCBieSB0aGUgYWdl bnQuICBMZWFkaW5nIHplcm9zIHNoYWxsDQogICAgICAgICAgICAgICAgIGJl IGluc2VydGVkIHRvIGZpbGwgdGhlIGVudGlyZSA4IG9jdGV0IGZpZWxkLg0K DQoNCkZvciBJUERTIG9uIHRoZSBPUy80MDAgcGxhdGZvcm06DQoNCiAgb2N0 ZXQgMTogICAnRycNCg0KICBvY3RldHMgMi00MDogIENvbnRhaW5zIGJ5dGVz IDItMzYgb2YgdGhlIFhPSCBEZWZpbmUgR3JvdXAgQm91bmRhcnkNCiAgICAg ICAgICAgICAgICBHcm91cCBJRCB0cmlwbGV0LiBPY3RldCBwb3NpdGlvbiAy IG11c3QgY2FycnkgdGhlIHZhbHVlDQogICAgICAgICAgICAgICAgeJIwM5Iu Qnl0ZXMgMzctNDAgbXVzdCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuDQoNCiAg b2N0ZXRzIDQxLTQ4OiAgQ29udGFpbnMgYSBkZWNpbWFsIChBU0NJSSBjb2Rl ZCkgcmVwcmVzZW50YXRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAgIGpt Sm9iSW5kZXggYXNzaWduZWQgYnkgdGhlIGFnZW50LiAgTGVhZGluZyB6ZXJv cyBzaGFsbA0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgOV0NDA0K SU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wg TWFwcGluZyAgICAgICAgIEZlYiAyLCAxOTk4DQoNCg0KDQoNCiAgICAgICAg ICAgICAgICAgYmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0 ZXQgZmllbGQuDQoNCg0KNS4yICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBl ZCB0byBJUERTDQoNCkZvciBNVlMvVlNFLg0KDQpNSUIgYXR0cmlidXRlICAg ICAgICAgICAgICB8IElQRFMgWE9IIERHQiBHcm91cCBJRCAgICAgICAgfCBE YXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9iU291 cmNlUGxhdGZvcm1UeXBlICAgICAgfCBCeXRlIDIgPSB4kjAxkiAgICAgICAg ICAgICAgIHwgSW50ZWdlcg0Kam9iTmFtZSAgICAgICAgICAgICAgICAgICAg fCBCeXRlcyA0LTExICAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5n DQoNCg0KRm9yIFZNLg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICB8 IElQRFMgWE9IIERHQiBHcm91cCBJRCAgICAgICAgfCBEYXRhIHR5cGUNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9iU291cmNlUGxhdGZvcm1U eXBlICAgICAgfCBCeXRlIDIgPSB4kjAykiAgICAgICAgICAgICAgIHwgSW50 ZWdlcg0KZmlsZU5hbWUgICAgICAgICAgICAgICAgICAgfCBCeXRlcyA0LTEx ICAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KRm9yIE9T LzQwMC4NCg0KTUlCIGF0dHJpYnV0ZSAgICAgICAgICAgICAgfCBJUERTIFhP SCBER0IgR3JvdXAgSUQgICAgICAgIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0NCmpvYlNvdXJjZVBsYXRmb3JtVHlwZSAgICAg IHwgQnl0ZSAyID0geJIwMpIgICAgICAgICAgICAgICB8IEludGVnZXINCmZp bGVOYW1lICAgICAgICAgICAgICAgICAgIHwgQnl0ZXMgMjMtMzIgICAgICAg ICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iTmFtZSAgICAgICAgICAg ICAgICAgICAgfCBCeXRlcyAzNy00NiAgICAgICAgICAgICAgICAgIHwgT2N0 ZXQgU3RyaW5nDQoNCg0KDQo2LjAgIERPQ1VNRU5UIFBSSU5USU5HIEFQUExJ Q0FUSU9OIChEUEEpDQoNClRoZSBJU08gMTAxNzUgRG9jdW1lbnQgUHJpbnRp bmcgQXBwbGljYXRpb24gKERQQSkgW0RQQV0gc3VwcG9ydHMNCnByaW50aW5n IHVzaW5nIGFueSBvbmUgb2YgdGhlIHRocmVlIHBvc3NpYmxlIGNvbmZpZ3Vy YXRpb25zLiAgRm9yDQpjb25maWd1cmF0aW9uIDIsIHRoZSBtYXBwaW5nIGRl ZmluZWQgaGVyZWluIGlzIHBlcmZvcm1lZCBvbiBhIHNlcnZlci4NCk90aGVy d2lzZSwgdGhlIG1hcHBpbmcgaXMgcGVyZm9ybWVkIG9uIGFuIGFnZW50IHdp dGhpbiB0aGUgcHJpbnRlci4NCg0KDQo2LjEgIGptSm9iU3VibWlzc2lvbklE IE1hcHBlZCB0byBEUEENCg0KRFBBIGNvbnRhaW5zIGEgcmljaCBzZXQgb2Yg cGFyYW1ldGVycyB3aGljaCBhbGxvdyBzZXZlcmFsIG1ldGhvZHMgb2YNCmNy ZWF0aW5nIHRoZSBqbUpvYlN1Ym1pc3Npb25JRCBvYmplY3QuICBUbyBwcmV2 ZW50IGludGVyb3BlcmFiaWxpdHkNCnByb2JsZW1zLCB0aGUgcHJlZmVycmVk IG1ldGhvZCBpcyB0byB1c2UgdGhlIERQQSBqb2Itb3JpZ2luYXRpbmctdXNl cg0KYXR0cmlidXRlIGFzIGZvbGxvd3M6DQoNCiAgb2N0ZXQgMTogICAnMCcN Cg0KICBvY3RldHMgMi00MDogIENvbnRhaW5zIHRoZSBEUEEgam9iLW93bmVy IGF0dHJpYnV0ZQ0KICAgICAgICAgICAgICAgIHN1cHBsaWVkIGJ5IHRoZSBz dWJtaXR0ZXIuICBJZiB0aGUgam9iLW93bmVyDQogICAgICAgICAgICAgICAg aXMgbGVzcyB0aGFuIDQwIG9jdGV0cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0 ZXIgaW4gdGhlDQogICAgICAgICAgICAgICAgc3RyaW5nIHNoYWxsIGFwcGVh ciBpbiBvY3RldCBwb3NpdGlvbiAyLiAgQW55IHVudXNlZA0KDQoNCg0KQmVy Z21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAg ICAgICAgICAgICAgICAgW3BhZ2UgMTBdDQwNCklOVEVSTkVULURSQUZUICAg ICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBG ZWIgMiwgMTk5OA0KDQoNCg0KDQogICAgICAgICAgICAgICAgcG9ydGlvbiBv ZiB0aGlzIGZpZWxkIHNoYWxsIGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4NCiAg ICAgICAgICAgICAgICBPdGhlcndpc2UsIG9ubHkgdGhlIGxhc3QgMzkgYnl0 ZXMgc2hhbGwgYmUgaW5jbHVkZWQuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgQ29u dGFpbnMgYW4gOC1kaWdpdCBzZXF1ZW50aWFsIGRlY2ltYWwgbnVtYmVyLg0K DQoNCjYuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gRFBBDQoNClRoZSBqb2Ig aW5kZXggKGptSm9iSW5kZXgpIGFzc2lnbmVkIGJ5IHRoZSBTTk1QIGpvYiBt b25pdG9yaW5nIGFnZW50IGlzDQpyZXR1cm5lZCB0byB0aGUgY2xpZW50IGJ5 IERQQSBhcyBhIGRlY2ltYWwgZGlnaXQgc3RyaW5nIGFzIHRoZSB2YWx1ZSBv Zg0KdGhlIERQQSBqb2ItaWRlbnRpZmllciBhdHRyaWJ1dGUuICAoU2luY2Ug RFBBIGRvZXMgbm90IHJlcXVpcmUNCmNvbnNlY3V0aXZlbHkgZ2VuZXJhdGVk IGpvYi1pZGVudGlmaWVycywgdGhlIGFnZW50IG1heSByZWNlaXZlIGpvYnMg ZnJvbQ0KbXVsdGlwbGUgY2xpZW50cyBhbmQgY2FuIGFzc2lnbiB0aGUgam1K b2JJbmRleCBpbiBhbiBhc2NlbmRpbmcgc2VxdWVuY2UNCmluZGVwZW5kZW50 IG9mIHRoZSBzdWJtaXR0aW5nIGpvYiBjbGllbnQuKSAgVGhlIERQQSBqb2It aWRlbnRpZmllciBtdXN0DQpiZSByZXN0cmljdGVkIHRvIHRoZSByYW5nZSBv ZiAxIHRvIDk5LDk5OSw5OTkgKGRlY2ltYWwpIHRvIGFsbG93IHRoZQ0KdmFs dWUgdG8gYmUgcHJvcGVybHkgcmVwcmVzZW50ZWQgaW4gam1Kb2JTdWJtaXNz aW9uSUQuDQoNCg0KNi4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8g RFBBDQoNCk1JQiBPYmplY3QgICAgICAgICAgICAgICAgICAgICAgIHwgRFBB IEpvYiBhdHRyaWJ1dGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpt Sm9iU3RhdGUgICAgICAgICAgICAgICAgICAgICAgIHwgam9iLXN0YXRlDQpq bUpvYlN0YXRlUmVhc29uczEgICAgICAgICAgICAgICB8IGpvYi1zdGF0ZS1y ZWFzb25zIChub3RlIDIpDQpqbU51bWJlck9mSW50ZXJ2ZW5pbmdKb2JzICAg ICAgICB8IGludGVydmVuaW5nLWpvYnMNCmptSm9iS09jdGV0c1BlckNvcHlS ZXF1ZXN0ZWQgICAgIHwgdG90YWwtam9iLW9jdGV0cyAobm90ZXMgMSwgMykN CmptSm9iS09jdGV0c1Byb2Nlc3NlZCAgICAgICAgICAgIHwgam9iLW9jdGV0 cy1jb21wbGV0ZWQgKG5vdGUgMSkNCmptSm9iSW1wcmVzc2lvbnNQZXJDb3B5 UmVxdWVzdGVkIHwgam9iLWltcHJlc3Npb24tY291bnQgKG5vdGUgMykNCmpt Sm9iSW1wcmVzc2lvbnNDb21wbGV0ZWQgICAgICAgIHwgaW1wcmVzc2lvbnMt Y29tcGxldGVkDQpqbUpvYk93bmVyICAgICAgICAgICAgICAgICAgICAgICB8 IGpvYi1vd25lcg0KDQogTm90ZXM6DQogLS0tLS0tDQogIDEuIGptSm9iS09j dGV0c1BlckNvcHlSZXF1ZXN0ZWQgYW5kIGptSm9iS09jdGV0c1Byb2Nlc3Nl ZCBpcyBpbiBLDQogICAgIG9jdGV0cyB3aGlsZSB0aGUgRFBBIGpvYi10b3Rh bC1vY3RldHMgYW5kIGpvYi1vY3RldHMtY29tcGxldGVkIGlzDQogICAgIGlu IG9jdGV0cyBhbmQgaXMgNjMtYml0cyBvZiBzaWduaWZpY2FuY2UuDQogIDIu IGpvYlN0YXRlUmVhc29uc04gaXMgYSBiaXQgbWFwIGRlc2NyaWJlZCBpbiBv bmUgb2JqZWN0IGFuZCB0aHJlZQ0KICAgICBhdHRyaWJ1dGVzLiAgVGhlIERQ QSBjb25kaXRpb24gbWF5IGNoYW5nZSBvbmUgb3IgbW9yZSBvZiB0aGUgYml0 cw0KICAgICBpbiBvbmUgb3IgbW9yZSBvZiB0aGVzZSBKb2IgTUlCIGl0ZW1z LiAgQWxzbyB0aGUgRFBBDQogICAgIGpvYi1zdGF0ZS1yZWFzb25zIGlzIGEg bXVsdGktdmFsdWVkIGF0dHJpYnV0ZSB3aXRoIGVhY2ggdmFsdWUgYmVpbmcN CiAgICAgYW4gT0JKRUNUIElERU5USUZJRVIgKE9JRCkuDQogIDMuIERQQSBv Y3RldHMgaW5jbHVkZSB0aGUgbXVsdGlwbGljYXRpb24gZmFjdG9yIGR1ZSB0 byBqb2IgYW5kDQogICAgIGRvY3VtZW50IGNvcGllcywgd2hpbGUgdGhlIE1J QiB2YWx1ZXMgZG8gbm90Lg0KDQoNCjYuNCAgVGhlIEF0dHJpYnV0ZSBHcm91 cCBNYXBwZWQgdG8gRFBBDQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJl IHJlcXVpcmVkIGlmIHRoZSBsaXN0ZWQgRFBBIGpvYiBhdHRyaWJ1dGUgaXMN CnByb3ZpZGVkLg0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgMTFdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9u IFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMiwgMTk5OA0KDQoNCg0K DQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IERQQSBqb2IgYXR0cmli dXRlICAgICAgICAgICAgfElQUCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLQ0Kam9iU3RhdGVSZWFzb25zTiAgICAgICAgICAgfCBq b2Itc3RhdGUtcmVhc29ucyAobm90ZSAyKSAgIHwgSW50ZWdlcg0Kam9iQ29k ZWRDaGFyU2V0ICAgICAgICAgICAgfCAobm90ZSAxKSAgICAgICAgICAgICAg ICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JBY2NvdW50TmFtZSAgICAgICAg ICAgICB8IGFjY291bnRpbmctaW5mb3JtYXRpb24gICAgICAgfCBPY3RldCBT dHJpbmcNCmpvYk5hbWUgICAgICAgICAgICAgICAgICAgIHwgam9iLW5hbWUg ICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KZGV2aWNlTmFt ZVJlcXVlc3RlZCAgICAgICAgfCBwcmludGVyLW5hbWUtcmVxdWVzdGVkICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpwaHlzaWNhbERldmljZSAgICAgICAgICAg ICB8IHByaW50ZXJzLWFzc2lnbmVkICAgICAgICAgICAgfCBPY3RldCBTdHJp bmcNCm51bWJlck9mRG9jdW1lbnRzICAgICAgICAgIHwgbnVtYmVyLW9mLWRv Y3VtZW50cyAgICAgICAgICB8IEludGVnZXINCmZpbGVOYW1lICAgICAgICAg ICAgICAgICAgIHwgZmlsZS1uYW1lICAgICAgICAgICAgICAgICAgICB8IE9j dGV0IFN0cmluZw0KZG9jdW1lbnROYW1lICAgICAgICAgICAgICAgfCBkb2N1 bWVudC1uYW1lICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JD b21tZW50ICAgICAgICAgICAgICAgICB8IGpvYi1jb21tZW50ICAgICAgICAg ICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmRvY3VtZW50Rm9ybWF0ICAgICAg ICAgICAgIHwgZG9jdW1lbnQtZm9ybWF0ICAgICAgICAgICAgICB8IE9jdGV0 IFN0cmluZw0Kam9iUHJpb3JpdHkgICAgICAgICAgICAgICAgfCBqb2ItcHJp b3JpdHkgICAgICAgICAgICAgICAgIHwgSW50ZWdlcg0Kam9iUHJvY2Vzc0Fm dGVyRGF0ZUFuZFRpbWUgfCBqb2ItcHJpbnQtYWZ0ZXIgICAgICAgICAgICAg IHwgT2N0ZXQgU3RyaW5nDQpvdXRwdXRCaW4gICAgICAgICAgICAgICAgICB8 IHJlc3VsdHMtcHJvZmlsZS5vdXRwdXQtYmluICAgfCBPY3RldCBTdHJpbmcN CnNpZGVzICAgICAgICAgICAgICAgICAgICAgIHwgc2lkZXMgKG5vdGUgMykg ICAgICAgICAgICAgICB8IEludGVnZXINCmZpbmlzaGluZyAgICAgICAgICAg ICAgICAgIHwgam9iLWZpbmlzaGluZywgZmluaXNoaW5nICAgICB8IEludGVn ZXINCnByaW50UXVhbGl0eVJlcXVlc3RlZCAgICAgIHwgcHJpbnQtcXVhbGl0 eSAgICAgICAgICAgICAgICB8IEludGVnZXINCnByaW50ZXJSZXNvbHV0aW9u UmVxdWVzdGVkIHwgZGVmYXVsdC1wcmludGVyLXJlc29sdXRpb24gICB8IElu dGVnZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChub3RlIDQp ICAgICAgICAgICAgICAgICAgICB8DQpqb2JDb3BpZXNSZXF1ZXN0ZWQgICAg ICAgICB8IHJlc3VsdHMtcHJvZmlsZS5qb2ItY29waWVzICAgfCBJbnRlZ2Vy DQpqb2JDb3BpZXNDb21wbGV0ZWQgICAgICAgICB8IGpvYi1jb3BpZXMtY29t cGxldGVkICAgICAgICAgfCBJbnRlZ2VyDQpkb2N1bWVudENvcGllc1JlcXVl c3RlZCAgICB8IGNvcHktY291bnQgKG5vdGUgNSkgICAgICAgICAgfCBJbnRl Z2VyDQpkb2N1bWVudENvcGllc0NvbXBsZXRlZCAgICB8IGNvcGllcy1jb21w bGV0ZWQgKG5vdGUgNikgICAgfCBJbnRlZ2VyDQpzaGVldHNSZXF1ZXN0ZWQg ICAgICAgICAgICB8IGpvYi1tZWRpYS1zaGVldC1jb3VudCAgICAgICAgfCBJ bnRlZ2VyDQpzaGVldHNDb21wbGV0ZWQgICAgICAgICAgICB8IGpvYi1tZWRp YS1zaGVldHMtY29tcGxldGVkICAgfCBJbnRlZ2VyDQpwYWdlc1JlcXVlc3Rl ZCAgICAgICAgICAgICB8IGpvYi1wYWdlLWNvdW50ICAgICAgICAgICAgICAg fCBJbnRlZ2VyDQpwYWdlc0NvbXBsZXRlZCAgICAgICAgICAgICB8IHBhZ2Vz LWNvbXBsZXRlZCAgICAgICAgICAgICAgfCBJbnRlZ2VyDQptZWRpdW1SZXF1 ZXN0ZWQgICAgICAgICAgICB8IHBhZ2UtbWVkaWEtc2VsZWN0LCAgICAgICAg ICAgfCBPY3RldCBTdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgIGRlZmF1bHQtbWVkaXVtICAgICAgICAgICAgICB8DQpqb2JTdWJtaXNz aW9uVGltZSAgICAgICAgICB8IHN1Ym1pc3Npb24tdGltZSAobm90ZSA3KSAg ICAgfCBPY3RldCBTdHJpbmcNCmpvYlN0YXJ0ZWRQcm9jZXNzaW5nVGltZSAg IHwgc3RhcnRlZC1wcmludGluZy10aW1lIChub3RlIDcpIE9jdGV0IFN0cmlu Zw0Kam9iQ29tcGxldGlvblRpbWUgICAgICAgICAgfCBjb21wbGV0aW9uLXRp bWUgKG5vdGUgNykgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCiBOb3RlczoNCiAt LS0tLS0NCiAgMS4gRXZlcnkgRFBBIGF0dHJpYnV0ZSBpcyB0YWdnZWQgaW5k aWNhdGluZyB0aGUgY29kZWQgY2hhcmFjdGVyIHNldA0KICAgICB0byBiZSB1 c2VkIGZvciB0aGF0IGF0dHJpYnV0ZS4NCiAgMi4gam9iU3RhdGVSZWFzb25z TiBpcyBhIGJpdCBtYXAgZGVzY3JpYmVkIGluIG9uZSBvYmplY3QgYW5kIHRo cmVlDQogICAgIGF0dHJpYnV0ZXMuICBUaGUgRFBBIGNvbmRpdGlvbiBtYXkg Y2hhbmdlIG9uZSBvciBtb3JlIG9mIHRoZSBiaXRzDQogICAgIGluIG9uZSBv ciBtb3JlIG9mIHRoZXNlIEpvYiBNSUIgaXRlbXMuICBBbHNvIHRoZSBEUEEN CiAgICAgam9iLXN0YXRlLXJlYXNvbnMgaXMgYSBtdWx0aS12YWx1ZWQgYXR0 cmlidXRlIHdpdGggZWFjaCB2YWx1ZSBiZWluZw0KICAgICBhbiBPQkpFQ1Qg SURFTlRJRklFUiAoT0lEKS4NCiAgMy4gVGhlIEpvYiBNSUIgc2lkZXMgYXR0 cmlidXRlIGlzIGFuIGludGVnZXIgJzEnIG9yICcyJyB3aGlsZSB0aGUgRFBB DQogICAgIHNpZGVzIGF0dHJpYnV0ZSBoYXMgb25lIG9mIHNpeCBPSUQgdmFs dWVzIHRoYXQgaW5jbHVkZXMgcGxleC4NCiAgNC4gcHJpbnRlclJlc29sdXRp b25SZXF1ZXN0ZWQgaGFzIHggYW5kIHkgcmVzb2x1dGlvbiBhbmQgaXMgaW50 ZW5kZWQNCiAgICAgdG8gb3ZlcnJpZGUgdGhlIHJlc29sdXRpb24gaW5zdHJ1 Y3Rpb24gaW4gdGhlIGRvY3VtZW50LCBpZiBhbnksDQogICAgIHdoaWxlIHRo ZSBEUEEgZGVmYXVsdC1wcmludGVyLXJlc29sdXRpb24gaXMgdGhlIHNhbWUg aW4geCBhbmQgeSBhbmQNCiAgICAgb25seSB0YWtlcyBlZmZlY3QgaWYgdGhl IGRvY3VtZW50IGRvZXMgbm90IGNvbnRhaW4gYSByZXNvbHV0aW9uDQogICAg IGluc3RydWN0aW9uDQogIDUuIFRoZSBEUEEgImNvcHktY291bnQiIGF0dHJp YnV0ZSBpcyBhIHBlci1kb2N1bWVudCBhdHRyaWJ1dGUsIHNvIHRoZQ0KDQoN Cg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwg ICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTJdDQwNCklOVEVSTkVULURS QUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAg ICAgICBGZWIgMiwgMTk5OA0KDQoNCg0KDQogICAgIE1JQiB2YWx1ZSBpcyB0 aGUgc3VtIG9mIHRoZSBkb2N1bWVudHMnICJjb3B5LWNvdW50IiB2YWx1ZXMg dGltZXMNCiAgICAgdGhlIGpvYidzICJyZXN1bHRzLXByb2ZpbGUuam9iLWNv cGllcyIgdmFsdWUuDQogIDYuIFRoZSBEUEEgImNvcGllcy1jb21wbGV0ZWQi IGF0dHJpYnV0ZSBpcyBhIHBlci1kb2N1bWVudCBhdHRyaWJ1dGUsDQogICAg IHNvIHRoZSBNSUIgdmFsdWUgaXMgdGhlIHN1bSBvZiB0aGUgZG9jdW1lbnRz JyAiY29waWVzLWNvbXBsZXRlZCINCiAgICAgdmFsdWVzIHRpbWVzIHRoZSBq b2IncyAicmVzdWx0cy1wcm9maWxlLmpvYi1jb3BpZXMiIHZhbHVlLg0KICA3 LiBUaGUgRFBBIEdlbmVyYXRsaXplZFRpbWUgZGF0YSB0eXBlIGlzIGRlZmlu ZWQgYnkgSVNPIDg4MjQNCiAgICAgKElTTy04ODI0KSB3aGlsZSB0aGUgTUlC IERhdGVBbmRUaW1lIGlzIGRlZmluZWQgYnkgU05NUHYyLVRDLg0KDQoNCg0K Ny4wICBOT1ZFTEwgRElTVFJJQlVURUQgUFJJTlQgU0VSVklDRSAoTkRQUykN Cg0KTm92ZWxsIERpc3RyaWJ1dGVkIFByaW50IFNlcnZpY2VzIGlzIGEgRFBB IGJhc2VkIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sDQp0aGF0IGNvbmZvcm1z IHRvIGNvbmZpZ3VyYXRpb24gMy4NCg0KDQo3LjEgIGptSm9iU3VibWlzc2lv bklEIE1hcHBlZCB0byBORFBTDQoNCk5EUFMgc3VwcG9ydHMgdGhlIGdlbmVy YXRpb24gb2YgYSBwcm9wZXJseSBmb3JtYXR0ZWQgam1Kb2JTdWJtaXNzaW9u SUQNCmZvciB1c2UgaW4gdGhlIEpvYiBNSUIsIHZpYSB0aGUgYXR0cmlidXRl IG5kcHMtYXR0LWpvYi1pZGVudGlmaWVyLg0KDQpJU1NVRTogSXMgdGhpcyB0 aGUgcHJvcGVyIE5EUFMgYXR0cmlidXRlIG9yIHNob3VsZCB0aGUgYXR0cmli dXRlIG5kcHMtDQphdHQtaWRlbnRpZmllci1vbi1jbGllbnQgb3IgbmRwcy1h dHQtbmV3LWpvYi1pZGVudGlmaWVyIHRvIGJlIHVzZWQ/DQoNCg0KNy4yICBq bUpvYkluZGV4IE1hcHBlZCB0byBORFBTDQoNCk5EUFMgZGVmaW5lcyB0aGUg YXR0cmlidXRlIG5kcHMtYXR0LWpvYi1pZGVudGlmaWVyLW9uLXByaW50ZXIg dGhhdCBjYW4NCmJlIHVzZWQgdG8gcmV0dXJuIHRoZSB2YWx1ZSBvZiBqbUpv YkluZGV4IHRvIHRoZSBORFBTIGNsaWVudC4NCg0KDQo3LjMgIE90aGVyIE1J QiBPYmplY3RzIE1hcHBlZCB0byBORFBTDQoNCk1JQiBPYmplY3QgICAgICAg ICAgICAgICAgICAgICAgIHwgTkRQUyBQYXJhbWV0ZXINCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0Kam1Kb2JTdGF0ZSAgICAgICAgICAgICAgICAg ICAgICAgfCBuZHBzLWF0dC1jdXJyZW50LWpvYi1zdGF0ZSAobm90ZSAxKQ0K am1Kb2JTdGF0ZVJlYXNvbnMxICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1q b2Itc3RhdGUtcmVhc29ucyAobm90ZSAyKQ0Kam1OdW1iZXJPZkludGVydmVu aW5nSm9icyAgICAgICAgfCBuZHBzLWF0dC1pbnRlcnZlbmluZy1qb2JzDQpq bUpvYktPY3RldHNQZXJDb3B5UmVxdWVzdGVkICAgICB8IG5kcHMtYXR0LXRv dGFsLWpvYi1vY3RldHMgKG5vdGVzIDMsNCkNCmptSm9iS09jdGV0c1Byb2Nl c3NlZCAgICAgICAgICAgIHwgbmRwcy1hdHQtb2N0ZXRzLWNvbXBsZXRlZCAo bm90ZSAzKQ0Kam1Kb2JJbXByZXNzaW9uc1BlckNvcHlSZXF1ZXN0ZWQgfCBu ZHBzLWF0dC1qb2ItaW1wcmVzc2lvbnMtY291bnQNCmptSm9iSW1wcmVzc2lv bnNDb21wbGV0ZWQgICAgICAgIHwgbmRwcy1hdHQtaW1wcmVzc2lvbnMtY29t cGxldGVkDQpqbUpvYk93bmVyICAgICAgICAgICAgICAgICAgICAgICB8IG5k cHMtYXR0LWpvYi1vd25lciAobm90ZSA1KQ0KDQogTm90ZXM6DQogLS0tLS0t DQogIDEuIFNvbWUgb2YgdGhlIE5EUFMgam9iIHN0YXRlcyBtdXN0IGJlIHJl cHJlc2VudGVkIGJ5IGJvdGggYQ0KICAgICBqbUpvYlN0YXRlIGFuZCBhIGpt Sm9iU3RhdGVSZWFzb25zMSBvYmplY3Qgb3IgYSBqb2JTdGF0ZVJlYXNvbnNO DQogICAgIGF0dHJpYnV0ZS4NCiAgMi4gVGhlIE5EUFMgam9iIHN0YXRlIHJl YXNvbnMgbWF5IGJlIG1hcHBlZCB0byBlaXRoZXIgdGhlIG9iamVjdA0KICAg ICBqbUpvYlN0YXRlUmVhc29uczEgb3IgdGhlIGF0dHJpYnV0ZSBqb2JTdGF0 ZVJlYXNvbnNOLg0KICAzLiBqbUpvYktPY3RldHNQZXJDb3B5UmVxdWVzdGVk IGFuZCBqbUpvYktPY3RldHNQcm9jZXNzZWQgaXMgaW4gSw0KDQoNCg0KQmVy Z21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAg ICAgICAgICAgICAgICAgW3BhZ2UgMTNdDQwNCklOVEVSTkVULURSQUZUICAg ICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBG ZWIgMiwgMTk5OA0KDQoNCg0KDQogICAgIG9jdGV0cyB3aGlsZSB0aGUgTkRQ UyBuZHBzLWF0dC1qb2ItdG90YWwtb2N0ZXRzIGFuZA0KICAgICBuZHBzLWF0 dC1qb2Itb2N0ZXRzLWNvbXBsZXRlZCBpcyBpbiBvY3RldHMgYW5kIGlzIDYz LWJpdHMgb2YNCiAgICAgc2lnbmlmaWNhbmNlLg0KICA0LiBORFBTIG9jdGV0 cyBpbmNsdWRlIHRoZSBtdWx0aXBsaWNhdGlvbiBmYWN0b3IgZHVlIHRvIGpv YiBhbmQNCiAgICAgZG9jdW1lbnQgY29waWVzLCB3aGlsZSB0aGUgTUlCIHZh bHVlcyBkbyBub3QuDQogIDUuIFRoZSBKb2IgTUlCIG9iamVjdCBtdXN0IGJl IG11bHRpcGxpZWQgYnkgdGhlIGF0dHJpYnV0ZQ0KICAgICBqb2JDb3BpZXNS ZXF1ZXN0ZWQgdG8gb2J0YWluIHRoZSBORFBTIGF0dHJpYnV0ZSB2YWx1ZSwg aWYgbXVsdGlwbGUNCiAgICAgY29waWVzIGhhdmUgYmVlbiByZXF1ZXN0ZWQu DQoNCg0KNy40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBORFBT DQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlmIHRo ZSBsaXN0ZWQgUEpMIGF0dHJpYnV0ZSBvcg0KY29tbWFuZCBvcHRpb24gaXMg cHJvdmlkZWQuDQoNCk1JQiBhdHRyaWJ1dGUgICAgICAgICAgICAgIHwgTkRQ UyBwYXJhbWV0ZXIgICAgICAgICAgICAgICB8IERhdGEgdHlwZQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tDQpqb2JBY2NvdW50TmFtZSAgICAgICAg ICAgICB8IG5kcHMtYXR0LWpvYi1vd25lciAgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCmpvYk5hbWUgICAgICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQt am9iLW5hbWUgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iT3JpZ2lu YXRpbmdIb3N0ICAgICAgICAgfCBuZHBzLWF0dC1qb2Itb3JpZ2luYXRvciAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpkZXZpY2VOYW1lUmVxdWVzdGVkICAgICAg ICB8IG5kcHMtYXR0LXByaW50ZXItbmFtZS0tICAgICAgfCBPY3RldCBTdHJp bmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgcmVx dWVzdGVkICAgICAgICAgICB8DQpudW1iZXJPZkRvY3VtZW50cyAgICAgICAg ICB8IG5kcHMtYXR0LW51bWJlci1vZi1kb2N1bWVudHMgfCBJbnRlZ2VyDQpm aWxlTmFtZSAgICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LWRvY3VtZW50 LWZpbGUtbmFtZSAgfCBPY3RldCBTdHJpbmcNCmRvY3VtZW50TmFtZSAgICAg ICAgICAgICAgIHwgbmRwcy1hdHQtZG9jdW1lbnQtbmFtZSAgICAgICB8IE9j dGV0IFN0cmluZw0Kam9iQ29tbWVudCAgICAgICAgICAgICAgICAgfCBuZHBz LWF0dC1qb2ItY29tbWVudCAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpkb2N1 bWVudEZvcm1hdEluZGV4ICAgICAgICB8IG5kcHMtYXR0LXBydEludGVycHJl dGVySW5kZXggfCBJbnRlZ2VyDQpkb2N1bWVudEZvcm1hdCAgICAgICAgICAg ICB8IG5kcHMtYXR0LWRvY3VtZW50LWZvcm1hdCAgICAgfCBJbnRlZ2VyDQpq b2JQcmlvcml0eSAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LWpvYi1wcmlv cml0eSAgICAgICAgfCBJbnRlZ2VyDQpqb2JQcm9jZXNzQWZ0ZXJEYXRlQW5k VGltZSB8IG5kcHMtYXR0LWpvYi1wcmludC1hZnRlciAgICAgfCBPY3RldCBT dHJpbmcNCm91dHB1dEJpbiAgICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQt cmVzdWx0cy1wcm9maWxlICAgICB8IEludGVnZXINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIChub3RlIDEpICAgICAgICAgICAgICAgICAgICB8 DQpzaWRlcyAgICAgICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LXNpZGVz IChub3RlIDIpICAgICAgfCBJbnRlZ2VyDQpmaW5pc2hpbmcgICAgICAgICAg ICAgICAgICB8IG5kcHMtYXR0LWpvYi1maW5pc2hpbmcgICAgICAgfCBJbnRl Z2VyDQpwcmludFF1YWxpdHlSZXF1ZXN0ZWQgICAgICB8IG5kcHMtYXR0LXBy aW50LXF1YWxpdHkgICAgICAgfCBJbnRlZ2VyDQpwcmludGVyUmVzb2x1dGlv blJlcXVlc3RlZCB8IG5kcHMtYXR0LWRlZmF1bHQtcHJpbnRlci0tICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgcmVzb2x1dGlvbiAobm90 ZSAzKSAgICAgICAgIHwgSW50ZWdlcg0KcHJpbnRlclJlc29sdXRpb25Vc2Vk ICAgICAgfCBuZHBzLWF0dC1kZWZhdWx0LXJlc29sdXRpb25zLS0NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIHVzZWQgICAgICAgICAgICAgICAg ICAgICAgICB8IEludGVnZXINCmpvYkNvcGllc1JlcXVlc3RlZCAgICAgICAg IHwgbmRwcy1hdHQtcmVzdWx0cy1wcm9maWxlICAgICB8IEludGVnZXINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChub3RlIDQpICAgICAgICAg ICAgICAgICAgICB8DQpqb2JDb3BpZXNDb21wbGV0ZWQgICAgICAgICB8IG5k cHMtYXR0LWpvYi1jb3BpZXMtY29tcGxldGVkfCBJbnRlZ2VyDQpkb2N1bWVu dENvcGllc1JlcXVlc3RlZCAgICB8IG5kcHMtYXR0LWNvcHktY291bnQgICAg ICAgICAgfCBJbnRlZ2VyDQpkb2N1bWVudENvcGllc0NvbXBsZXRlZCAgICB8 IG5kcHMtYXR0LWNvcGllcy1jb21wbGV0ZWQgICAgfCBJbnRlZ2VyDQogICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAobm90ZSAzKQ0Kc2hlZXRzUmVx dWVzdGVkICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2ItbWVkaWEtLSAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICBzaGVldC1jb3VudCB8IEludGVnZXINCnNoZWV0c0NvbXBsZXRl ZCAgICAgICAgICAgIHwgbmRwcy1hdHQtbWVkaWEtc2hlZXRzLS0gICAgICB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICBjb21wbGV0ZWQgfCBJbnRlZ2VyDQptZWRpdW1Db25zdW1lZCAgICAg ICAgICAgICB8IG5kcHMtYXR0LW1lZGlhLXVzZWQgICAgICAgICAgfCBJbnRl Z2VyDQpqb2JTdWJtaXNzaW9uVG9TZXJ2ZXJUaW1lICB8IG5kcHMtYXR0LXN1 Ym1pc3Npb24tdGltZSAgICAgfCBPY3RldCBTdHJpbmcNCmpvYlN1Ym1pc3Np b25UaW1lICAgICAgICAgIHwgbmRwcy1hdHQtc3RhcnRlZC1wcmludGluZy10 aW1lIE9jdGV0IFN0cmluZw0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgMTRdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9u IFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMiwgMTk5OA0KDQoNCg0K DQpqb2JDb21wbGV0aW9uVGltZSAgICAgICAgICB8IG5kcHMtYXR0LWNvbXBs ZXRpb24tdGltZSAgICAgfCBPY3RldCBTdHJpbmcNCg0KIE5vdGVzOg0KIC0t LS0tLQ0KICAxLiBUaGUgb3V0cHV0LWJpbiBmaWVsZCBpbiBuZHBzLWF0dC1y ZXN1bHRzLXByb2ZpbGUgaXMgdG8gYmUgdXNlZC4NCiAgMi4gVGhlIEpvYiBN SUIgc2lkZXMgYXR0cmlidXRlIGlzIGFuIGludGVnZXIgJzEnIG9yICcyJyB3 aGlsZSB0aGUgTkRQUw0KICAgICBzaWRlcyBhdHRyaWJ1dGUgaGFzIG9uZSBv ZiBzaXggT0lEIHZhbHVlcyB0aGF0IGluY2x1ZGVzIHBsZXguDQogIDMuIHBy aW50ZXJSZXNvbHV0aW9uUmVxdWVzdGVkIGhhcyB4IGFuZCB5IHJlc29sdXRp b24gYW5kIGlzIGludGVuZGVkDQogICAgIHRvIG92ZXJyaWRlIHRoZSByZXNv bHV0aW9uIGluc3RydWN0aW9uIGluIHRoZSBkb2N1bWVudCwgaWYgYW55LA0K ICAgICB3aGlsZSB0aGUgbmRwcy1hdHQtZGVmYXVsdC1wcmludGVyLXJlc29s dXRpb24gaXMgdGhlIHNhbWUgaW4geCBhbmQNCiAgICAgeSBhbmQgb25seSB0 YWtlcyBlZmZlY3QgaWYgdGhlIGRvY3VtZW50IGRvZXMgbm90IGNvbnRhaW4g YQ0KICAgICByZXNvbHV0aW9uIGluc3RydWN0aW9uDQogIDQuIFRoZSBqb2It Y29waWVzIGZpZWxkIGluIG5kcHMtYXR0LXJlc3VsdHMtcHJvZmlsZSBpcyB0 byBiZSB1c2VkLg0KDQoNCg0KOC4wICBQUklOVEVSIEpPQiBMQU5HVUFHRSAo UEpMKQ0KDQpQSkwgW1BKTF0gaGFzIGJlZW4gZGV2ZWxvcGVkIGJ5IEhld2xl dHQtUGFja2FyZCB0byBwcm92aWRlIGpvYiBjb250cm9sDQppbmZvcm1hdGlv biB0byB0aGUgcHJpbnRlciBhbmQgc3RhdHVzIGluZm9ybWF0aW9uIHRvIGFw cGxpY2F0aW9ucywNCmluZGVwZW5kZW50IG9mIHRoZSBQREwuDQoNCg0KOC4x ICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gUEpMDQoNClBKTCBoYXMg ZGVmaW5lZCB0aGUgU1VCTUlTU0lPTklEIG9wdGlvbiBmb3IgdGhlIEpPQiBj b21tYW5kIHdoaWNoDQppbmRpY2F0ZXMgYSBwcm9wZXJseSBmb3JtYXR0ZWQg am1Kb2JTdWJtaXNzaW9uSUQgZm9yIHVzZSBpbiB0aGUgSm9iIE1JQi4NClRo ZSBQSkwgSk9CIGNvbW1hbmQgaXMgcHJlc2VudGVkIGF0IHRoZSBzdGFydCBv ZiBhIHByaW50IGpvYiB3aXRoDQpvcHRpb25zIHRoYXQgYXBwbHkgb25seSB0 aGUgYXR0YWNoZWQgam9iLiAgVGhlIHN5bnRheCBmb3IgdGhpcyBjb21tYW5k DQpvcHRpb24gaXM6DQoNCiAgICAgIEBQSkwgSk9CIFNVQk1JU1NJT05JRCA9 ICJpZCBzdHJpbmciDQoNCkRyaXZlciBzb2Z0d2FyZSB0aGF0IGltcGxlbWVu dHMgdGhpcyBQSkwgY29tbWFuZCBvcHRpb24gbXVzdCBwcm92aWRlIHRoZQ0K ImlkIHN0cmluZyIgaW4gb25lIG9mIHRoZSBjbGllbnQgdmVyc2lvbiBmb3Jt YXRzIHNwZWNpZmllZCBpbiB0aGUgSm9iDQpNSUIgZm9yIGptSm9iU3VibWlz c2lvbklELg0KDQpGb3IgZHJpdmVycyB0aGF0IGFyZSBub3QgYWJsZSB0byBj cmVhdGUgdGhlIFNVQk1JU1NJT05JRCBvcHRpb24sIGl0IGlzDQpyZWNvbW1l bmRlZCB0aGF0IGptSm9iU3VibWlzc2lvbklEIGZvcm1hdCAwIGJlIGNyZWF0 ZWQgYnkgdGhlIGFnZW50DQp1c2luZyB0aGUgUEpMIGF0dHJpYnV0ZSBEb2NP d25lciBvciBEb2NPd25lcklkLg0KDQogIG9jdGV0IDE6ICAgJzAnDQoNCiAg b2N0ZXRzIDItNDA6ICBDb250YWlucyB0aGUgc3RyaW5nIGFzc29jaWF0ZWQg d2l0aCBEb2NPd25lciBvcg0KICAgICAgICAgICAgICAgIERvY093bmVySWQu ICBJZiB0aGUgc3RyaW5nIGlzIGxlc3MgdGhhbiA0MCBvY3RldHMsIHRoZQ0K ICAgICAgICAgICAgICAgIGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlIHN0 cmluZyBzaGFsbCBhcHBlYXIgaW4gb2N0ZXQNCiAgICAgICAgICAgICAgICBw b3NpdGlvbiAyLiAgT3RoZXJ3aXNlLCBvbmx5IHRoZSBsYXN0IDM5IGJ5dGVz IHNoYWxsIGJlDQogICAgICAgICAgICAgICAgaW5jbHVkZWQuICBBbnkgdW51 c2VkIHBvcnRpb24gb2YgdGhpcyBmaWVsZCBzaGFsbCBiZQ0KICAgICAgICAg ICAgICAgIGZpbGxlZCB3aXRoIHNwYWNlcy4gIElmIERvY093bmVyIG9yIERv Y093bmVySWQgY2Fubm90IGJlDQogICAgICAgICAgICAgICAgb2J0YWluZWQs IHRoaXMgZmllbGQgc2hhbGwgYmUgYmxhbmsuDQoNCg0KDQoNCg0KQmVyZ21h biAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAg ICAgICAgICAgICAgW3BhZ2UgMTVdDQwNCklOVEVSTkVULURSQUZUICAgICAg IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIg MiwgMTk5OA0KDQoNCg0KDQogIG9jdGV0cyA0MS00ODogIENvbnRhaW5zIHRo ZSB2YWx1ZSBvZiBqbUpvYkluZGV4IGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAg ICAgICAgICAgICAgICAgam9iLiAgTGVhZGluZyB6ZXJvcyBzaGFsbCBiZSBp bnNlcnRlZCB0byBmaWxsIHRoZQ0KICAgICAgICAgICAgICAgICBlbnRpcmUg OCBvY3RldCBmaWVsZC4NCg0KDQo4LjIgIGptSm9iSW5kZXggTWFwcGVkIHRv IFBKTA0KDQpQSkwgZG9lcyBub3QgcHJvdmlkZSBhIHZhbHVlIHRoYXQgY2Fu IGJlIG1hcHBlZCB0byBqbUpvYkluZGV4Lg0KDQoNCjguMyAgT3RoZXIgTUlC IE9iamVjdHMgTWFwcGVkIHRvIFBKTA0KDQpNSUIgT2JqZWN0ICAgICAgICAg ICAgfCBQSkwgSm9iIGF0dHJpYnV0ZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpvYk93 bmVyICAgICAgICAgICAgICB8IERvY093bmVyIG9yIERvY093bmVySWQgYXR0 cmlidXRlDQoNCg0KOC40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0 byBQSkwNCg0KVGhlIGZvbGxvd2luZyBtYXBwaW5ncyBhcmUgcmVxdWlyZWQg aWYgdGhlIGxpc3RlZCBQSkwgYXR0cmlidXRlIG9yDQpjb21tYW5kIG9wdGlv biBpcyBwcm92aWRlZC4NCg0KTUlCIGF0dHJpYnV0ZSAgICAgICAgIHwgUEpM IGF0dHJpYnV0ZSBvciBjb21tYW5kIG9wdGlvbiAgfCBEYXRhIHR5cGUNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLQ0Kc2VydmVyQXNzaWduZWRKb2JO YW1lIHwgRG9jTmFtZSBhdHRyaWJ1dGUgb3IgdGhlIGNvbW1hbmQgfCBPY3Rl dCBTdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICB8ICBAUEpMIEpPQiBO YW1lID0gInN0cmluZyIgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpzdWJtaXR0 aW5nU2VydmVyTmFtZSAgfCBTcmNTZXJ2ZXJOYW1lIGF0dHJpYnV0ZSAgICAg ICAgICB8IE9jdGV0IFN0cmluZw0Kam9iT3JpZ2luYXRpbmdIb3N0ICAgIHwg U3JjUG9ydCBhdHRyaWJ1dGUgICAgICAgICAgICAgICAgfCBPY3RldCBTdHJp bmcNCnF1ZXVlTmFtZVJlcXVlc3RlZCAgICB8IFNyY1EgYXR0cmlidXRlICAg ICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpmaWxlTmFtZSAgICAg ICAgICAgICAgfCBKb2JGTmFtZSBhdHRyaWJ1dGUgICAgICAgICAgICAgICB8 IE9jdGV0IFN0cmluZw0Kam9iQ29tbWVudCAgICAgICAgICAgIHwgSm9iRGVz YyBhdHRyaWJ1dGUgICAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmpv YlN1Ym1pc3Npb25UaW1lICAgICB8IFRpbWVTdWJtaXQgYXR0cmlidXRlICAg ICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KDQo5LjAgIFBPU1RTQ1JJ UFQNCg0KVGhlIFBvc3RTY3JpcHQgUERMIHBlcm1pdHMgY29tbWVudCBmaWVs ZHMgd2hpY2ggY2FuIGJlIHVzZWQgYnkNCmFwcGxpY2F0aW9uIGRyaXZlcnMg dG8gaW5jbHVkZSBqb2IgaW5mb3JtYXRpb24uICBBbHRob3VnaCB0aGVyZSBh cmUgbm8NCnJlc3RyaWN0aW9ucyBvciByZXF1aXJlbWVudHMgYXMgdG8gd2hh dCBpbmZvcm1hdGlvbiBtYXkgYmUgaW5jbHVkZWQsDQptYW55IGRyaXZlcnMg aW5jbHVkZSBqb2Igb3duZXIgYW5kL29yIGRvY3VtZW50IG5hbWUuDQoNCg0K OS4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gUG9zdFNjcmlwdA0K DQpUaGUgdXNlIG9mIGEgc3RhbmRhcmQgZm9ybWF0IGpvYiBzdWJtaXNzaW9u IGlkIGNvbW1lbnQgc3RyaW5nIHdpbGwgYWxsb3cNCmludGVyb3BlcmFiaWxp dHkgb2YgcHJpbnRlcnMgYW5kIGRyaXZlcnMgZnJvbSBtdWx0aXBsZSB2ZW5k b3JzLiAgVGhlDQpmb2xsb3dpbmcgY29tbWVudCBzdHJpbmcgZm9ybWF0IGlz IHJlY29tbWVuZGVkIGZvciB1c2Ugd2l0aCBQb3N0U2NyaXB0DQpsZXZlbCAx IGFuZCBsZXZlbCAyIGRhdGEgc3RyZWFtcy4NCg0KICAgICAlJUpNUEpvYlN1 Ym1pc3Npb25JZDooaWQtc3RyaW5nKQ0KDQoNCg0KDQpCZXJnbWFuICAgICAg ICAgICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAg ICAgICBbcGFnZSAxNl0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1 Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAyLCAxOTk4 DQoNCg0KDQoNCndoZXJlICJpZCBzdHJpbmciIGNhbiBiZSBhbnkgam1Kb2JT dWJtaXNzaW9uSUQgZm9ybWF0IHJlc2VydmVkIGZvcg0KY2xpZW50cy4NCg0K OS4yICBPdGhlciBNSUIgT2JqZWN0cyBhbmQgQXR0cmlidXRlcyBNYXBwZWQg dG8gUG9zdFNjcmlwdA0KDQpObyBPdGhlciBtYXBwaW5ncyBmcm9tIFBvc3RT Y3JpcHQgY29tbWVudCBzdHJpbmdzIGFyZSByZWNvbW1lbmRlZCwgYnV0DQpt YW55IEpvYiBNSUIgb2JqZWN0cyBhbmQgYXR0cmlidXRlcyBjYW4gYmUgZGVm aW5lZCB1c2luZyB2ZW5kb3IgdW5pcXVlDQpjb21tZW50IHN0cmluZ3MuDQoN Cg0KDQoxMC4wICBORVRXQVJFIFBTRVJWRVINCg0KVGhlIE5ldFdhcmUgUFNl cnZlciBqb2Igc3VibWlzc2lvbiBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBp biBhIGNsaWVudC0NCnNlcnZlci1wcmludGVyIHN5c3RlbSBvbiB0aGUgc2Vy dmVyIHRvIHByaW50ZXIgbGluayBhcyBkZWZpbmVkIGluDQpjb25maWd1cmF0 aW9uIDMuDQoNCg0KMTAuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRv IFBTZXJ2ZXINCg0KICBvY3RldCAxOiAgICdCJw0KDQoNCiAgb2N0ZXRzIDIt NDA6ICBDb250YWlucyB0aGUgRGlyZWN0b3J5IFBhdGggTmFtZSBvZiB0aGUg YWdlbnQgYXMNCiAgICAgICAgICAgICAgICByZWNvcmRlZCBieSB0aGUgTm92 ZWxsIEZpbGUgU2VydmVyIGluIHRoZSBxdWV1ZQ0KICAgICAgICAgICAgICAg IGRpcmVjdG9yeS4gIElmIHRoZSBzdHJpbmcgaXMgbGVzcyB0aGFuIDQwIG9j dGV0cywgdGhlDQogICAgICAgICAgICAgICAgbGVmdC1tb3N0IGNoYXJhY3Rl ciBpbiB0aGUgc3RyaW5nIHNoYWxsIGFwcGVhciBpbiBvY3RldA0KICAgICAg ICAgICAgICAgIHBvc2l0aW9uIDIuICBPdGhlcndpc2UsIG9ubHkgdGhlIGxh c3QgMzkgYnl0ZXMgc2hhbGwgYmUNCiAgICAgICAgICAgICAgICBpbmNsdWRl ZC4gIEFueSB1bnVzZWQgcG9ydGlvbiBvZiB0aGlzIGZpZWxkIHNoYWxsIGJl DQogICAgICAgICAgICAgICAgZmlsbGVkIHdpdGggc3BhY2VzLg0KDQogIG9j dGV0cyA0MS00ODogICcwMDBYWFhYWCcgIFRoZSBkZWNpbWFsIChBU0NJSSBj b2RlZCkgcmVwcmVzZW50YXRpb24gb2YNCiAgICAgICAgICAgICAgICAgdGhl IEpvYiBOdW1iZXIgYXMgcGVyIHRoZSBOZXRXYXJlIEZpbGUgU2VydmVyIFF1 ZXVlDQogICAgICAgICAgICAgICAgIE1hbmFnZW1lbnQgU2VydmljZXMuDQoN Cg0KMTAuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gUFNlcnZlcg0KDQpUaGUg am9iIGluZGV4IChqbUpvYkluZGV4KSBpcyBhc3NpZ25lZCBieSB0aGUgU05N UCBqb2IgbW9uaXRvcmluZyBhZ2VudA0KYW5kIGlzIGluZGVwZW5kZW50IG9m IHRoZSBKb2IgTnVtYmVyIGFzc2lnbmVkIGJ5IHRoZSBOZXRXYXJlIEZpbGUg U2VydmVyDQpRdWV1ZSBNYW5hZ2VtZW50IFNlcnZpY2VzLiAgVGhpcyB3aWxs IGFsbG93IHRoZSBTTk1QIGFnZW50IHRvIHRyYWNrIGpvYnMNCnJlY2VpdmVk IGZyb20gbXVsdGlwbGUgc291cmNlcy4NCg0KDQoxMC4zICBPdGhlciBNSUIg T2JqZWN0cyBNYXBwZWQgdG8gUEpMDQoNCk1JQiBPYmplY3QgICAgICAgICAg ICB8IFBTZXJ2ZXIgSm9iIGF0dHJpYnV0ZQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpv Yk93bmVyICAgICAgICAgICAgICB8IENsaWVudCBJZCBOdW1iZXIgICAgICAg ICAgICB8IE9jdGV0IFN0cmluZw0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAg ICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAg ICAgICAgW3BhZ2UgMTddDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBT dWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMiwgMTk5 OA0KDQoNCg0KDQoxMC40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0 byBQU2VydmVyDQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVp cmVkIGlmIHRoZSBsaXN0ZWQgUFNlcnZlciBwYXJhbWV0ZXIgaXMNCnByb3Zp ZGVkIGluIHRoZSBOb3ZlbGwgRmlsZSBTZXJ2ZXIgcXVldWUgZGlyZWN0b3J5 Lg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IFBTZXJ2ZXIgcGFy YW1ldGVyICAgICAgICAgICB8IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tDQpzZXJ2ZXJBc3NpZ25lZEpvYk5hbWUgICAgICB8IEpv YiBGaWxlIE5hbWUgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KcXVl dWVOYW1lUmVxdWVzdGVkICAgICAgICAgfCBRdWV1ZSBJZCAgICAgICAgICAg ICAgICAgICAgfCBJbnRlZ2VyDQpwaHlzaWNhbERldmljZSAgICAgICAgICAg ICB8IFNlcnZlciBJZCBOdW1iZXIgICAgICAgICAgICB8IEludGVnZXINCmpv YkNvbW1lbnQgICAgICAgICAgICAgICAgIHwgSm9iIERlc2NyaXB0aW9uICAg ICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JQcmlvcml0eSAgICAgICAg ICAgICAgICB8IChub3RlIDEpICAgICAgICAgICAgICAgICAgICB8IEludGVn ZXINCmpvYlByb2Nlc3NBZnRlckRhdGVBbmRUaW1lIHwgVGFyZ2V0IEV4ZWN1 dGlvbiBUaW1lICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JDb3BpZXNSZXF1 ZXN0ZWQgICAgICAgICB8IE51bWJlciBvZiBDb3BpZXMgICAgICAgICAgICB8 IEludGVnZXINCm1lZGl1bVJlcXVlc3RlZCAgICAgICAgICAgIHwgRm9ybSBO YW1lICAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdWJt aXNzaW9uVG9TZXJ2ZXJUaW1lICB8IEpvYiBFbnRyeSBUaW1lICAgICAgICAg ICAgICB8IE9jdGV0IFN0cmluZw0KDQpOb3RlczoNCi0tLS0tLQ0KIDEuIFRo ZSBqb2IgcHJpb3JpdHkgaXMgZGV0ZXJtaW5lZCBieSB0aGUgcHJpb3JpdHkg YXNzaWduZWQgdG8gdGhlIHF1ZXVlDQogICAgdGhhdCBjb250YWlucyB0aGUg am9iLiAgRWFjaCBxdWV1ZSBjYW4gYmUgYXNzaWduZWQgYSB1bmlxdWUgcHJp b3JpdHkNCiAgICBhbmQgdGhlIHByaW9yaXR5IG9mIHRoZSBqb2IgaXMgaW5o ZXJpdGVkIGZyb20gdGhlIHF1ZXVlLg0KDQoNCg0KMTEuMCAgTkVUV0FSRSBO UFJJTlRFUiBvciBSUFJJTlRFUg0KDQpUaGUgTmV0V2FyZSBOUHJpbnRlci9S UHJpbnRlciBwcm90b2NvbCB3YXMgZGVzaWduZWQgdG8gdHJhbnNmZXIgcHJp bnQNCmRhdGEgZnJvbSBhIE5vdmVsbCBGaWxlIFNlcnZlciB0byBhIHByaW50 ZXIgYXR0YWNoZWQgZGlyZWN0bHkgdG8gYSBsb2NhbA0KcG9ydCAoZS5nLiBw YXJhbGxlbCBvciBzZXJpYWwpIG9uIGEgUEMuICBOUHJpbnRlci9SUHJpbnRl ciBpcyBhbg0KZXh0cmVtZWx5IGxpZ2h0d2VpZ2h0IHByaW50aW5nIHByb3Rv Y29sLiAgQ29uc2VxdWVudGx5LCBubyBpbmZvcm1hdGlvbg0KcmVxdWlyZWQg YnkgdGhlIEpvYiBNb25pdG9yaW5nIE1JQiBpcyBwcm92aWRlZCBhbmQgYSBt ZWFuaW5nZnVsDQpqbUpvYlN1Ym1pc3Npb25JRCBjYW5ub3QgYmUgZ2VuZXJh dGVkLg0KDQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGFuIGFkZGl0aW9uYWwg am9iIHN1Ym1pc3Npb24gbGF5ZXIsIHN1Y2ggYXMgUEpMDQpvciBhbm90aGVy IHZlbmRvciBwcml2YXRlIHByb3RvY29sLCAgYmUgaW5jbHVkZWQgb24gdG9w IG9mDQpOUHJpbnRlci9SUHJpbnRlciB0byBwcm92aWRlIHRoZSByZXF1aXJl ZCBpbmZvcm1hdGlvbi4gIFRoZSBtYXBwaW5nDQpzaG91bGQgdGhlbiBiZSBw ZXJmb3JtZWQgYWNjb3JkaW5nIHRvIHRoZSByZWNvbW1lbmRhdGlvbnMgb2Yg dGhlIGhpZ2hlcg0KbGF5ZXIgc3VibWlzc2lvbiBwcm90b2NvbC4NCg0KDQoN CjEyLjAgIFNFUlZFUiBNRVNTQUdFIEJMT0NLIChTTUIpIFBST1RPQ09MDQoN ClRoZSBTZXJ2ZXIgTWVzc2FnZSBCbG9jayBwcm90b2NvbCBpcyB1c2VkIHdp dGggc2V2ZXJhbCBQQyBOZXR3b3JrDQpvcGVyYXRpbmcgc3lzdGVtcywgc3Vj aCBhcyBNaWNyb3NvZnQgV2luZG93cyBmb3IgV29ya2dyb3VwcywgSUJNIExB Tg0KU2VydmVyLCBhbmQgQXJ0aXNvZnQgTGFudGFzdGljLiAgU01CIHN5c3Rl bXMgc3VwcG9ydGluZyB0aGUgSm9iDQpNb25pdG9yaW5nIE1JQiB3aWxsIGNv bmZvcm0gdG8gZWl0aGVyIGNvbmZpZ3VyYXRpb24gMSBvciAzLg0KDQoNCg0K DQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3JtYXRp b25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAxOF0NDA0KSU5URVJO RVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGlu ZyAgICAgICAgIEZlYiAyLCAxOTk4DQoNCg0KDQoNCjEyLjEgIGptSm9iU3Vi bWlzc2lvbklEIE1hcHBlZCB0byBTTUINCg0KICBvY3RldCAxOiAgICdDJw0K DQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgYSBkZWNpbWFsIChBU0NJSSBj b2RlZCkgcmVwcmVzZW50YXRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAg MTYgYml0IFNNQiBUcmVlIElkIGZpZWxkLCB3aGljaCB1bmlxdWVseSBpZGVu dGlmaWVzIHRoZQ0KICAgICAgICAgICAgICAgIGNvbm5lY3Rpb24gdGhhdCBz dWJtaXR0ZWQgdGhlIGpvYiB0byB0aGUgcHJpbnRlci4gIFRoZQ0KICAgICAg ICAgICAgICAgIG1vc3Qgc2lnbmlmaWNhbnQgZGlnaXQgb2YgdGhlIG51bWVy aWMgc3RyaW5nIHNoYWxsIGJlDQogICAgICAgICAgICAgICAgcGxhY2VkIGlu IG9jdGV0IHBvc2l0aW9uIDIuICBBbGwgdW51c2VkIHBvcnRpb25zIG9mIHRo aXMNCiAgICAgICAgICAgICAgICBmaWVsZCBzaGFsbCBiZSBmaWxsZWQgd2l0 aCBzcGFjZXMuICBUaGUgU01CIFRyZWUgSWQgaGFzDQogICAgICAgICAgICAg ICAgYSBtYXhpbXVtIHZhbHVlIG9mIDY1LDUzNS4NCg0KICBvY3RldHMgNDEt NDg6ICBDb250YWlucyBhIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNl bnRhdGlvbiBvZiB0aGUNCiAgICAgICAgICAgICAgICAgRmlsZSBIYW5kbGUg cmV0dXJuZWQgZnJvbSB0aGUgcHJpbnRlciBhZ2VudCB0byB0aGUNCiAgICAg ICAgICAgICAgICAgY2xpZW50IGluIHJlc3BvbnNlIHRvIGEgQ3JlYXRlIFBy aW50IEZpbGUgY29tbWFuZC4NCiAgICAgICAgICAgICAgICAgTGVhZGluZyB6 ZXJvcyBzaGFsbCBiZSBpbnNlcnRlZCB0byBmaWxsIHRoZSBlbnRpcmUgOA0K ICAgICAgICAgICAgICAgICBvY3RldCBmaWVsZC4NCg0KDQoxMi4yICBqbUpv YkluZGV4IE1hcHBlZCB0byBTTUINCg0KSXQgaXMgc3Ryb25nbHkgcmVjb21t ZW5kZWQgdGhhdCB0aGUgRmlsZSBIYW5kbGUgcmV0dXJuZWQgZnJvbSB0aGUN CnByaW50ZXIgYWdlbnQgYmUgaWRlbnRpY2FsIHRvIGptSm9iSW5kZXguICBJ ZiB0aGVzZSBpdGVtcyBhcmUgaWRlbnRpY2FsLA0KdGhlcmUgaXMgbm8gbmVl ZCBmb3IgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiB0byBwZXJmb3JtIGEgc2Vh cmNoIG9uDQpqbUpvYlN1Ym1pc3Npb25JRC4gIFRvIGJlIGNvbXBhdGlibGUg d2l0aCB0aGUgMTYgYml0IGZpZWxkIGFsbG9jYXRlZCB0bw0KdGhpcyB2YWx1 ZSBieSBTTUIsIHRoZSBtYXhpbXVtIGptSm9iSW5kZXggaXMgNjUsNTM1Lg0K DQoNCjEyLjMgIE90aGVyIE1JQiBvYmplY3RzIE1hcHBlZCB0byBTTUINCg0K TUlCIE9iamVjdCAgICAgIHwgU01CIFBhcmFtZXRlcg0KLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCmptSm9iT3duZXIgICAgICB8IFNNQiBVc2VyIElkIGZpZWxk IChub3RlIDEpDQoNCk5vdGVzOg0KLS0tLS0tDQogMS4gQSBkZWNpbWFsIChB U0NJSSBjb2RlZCkgcmVwcmVzZW50YXRpb24gb2YgdGhlIFNNQiBVc2VyIElk IG51bWVyaWMNCiAgICBzaGFsbCBiZSBwcmVzZW50ZWQgYXMgam1Kb2JPd25l ci4NCg0KDQoNCjEzLjAgIFRSQU5TUE9SVCBJTkRFUEVOREVOVCBQUklOVEVS L1NZU1RFTSBJTlRFUkZBQ0UgKFRJUC9TSSkNCg0KVGhlIFRJUC9TSSBwcm90 b2NvbCwgYWx0aG91Z2ggY3VycmVudGx5IHNwZWNpZmllZCBhcyBhIHBhcnQg b2YgdGhlIElFRUUNCjEyODQgcGFyYWxsZWwgcG9ydCBzdGFuZGFyZHMgW1RJ UC9TSV0sIHdhcyBvcmlnaW5hbGx5IGRldmVsb3BlZCBhcyBhDQpuZXR3b3Jr IHByb3RvY29sLiAgVElQL1NJIHRodXMgaGFzIHRoZSBwb3RlbnRpYWwgb2Yg YmVpbmcgaW50ZWdyYXRlZA0KaW50byBhbnkgbmV0d29yayBvciBub24tbmV0 d29yayBjb25maWd1cmF0aW9uLg0KDQoxMy4xICBqbUpvYlN1Ym1pc3Npb25J RCBNYXBwZWQgdG8gVElQL1NJDQoNCiAgb2N0ZXQgMTogICAnRCcNCg0KDQoN Cg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwg ICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTldDQwNCklOVEVSTkVULURS QUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAg ICAgICBGZWIgMiwgMTk5OA0KDQoNCg0KDQogIG9jdGV0cyAyLTQwOiAgQ29u dGFpbnMgdGhlIEpvYiBOYW1lIGZyb20gdGhlIEpvYiBDb250cm9sLVN0YXJ0 IEpvYg0KICAgICAgICAgICAgICAgIChKQy1TSikgY29tbWFuZC4gIElmIHRo ZSBKb2IgTmFtZSBwb3J0aW9uIGlzIGxlc3MgdGhhbg0KICAgICAgICAgICAg ICAgIDQwIG9jdGV0cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhl IHN0cmluZyBzaGFsbA0KICAgICAgICAgICAgICAgIGFwcGVhciBpbiBvY3Rl dCBwb3NpdGlvbiAyLiAgQW55IHVudXNlZCBwb3J0aW9uIG9mIHRoaXMNCiAg ICAgICAgICAgICAgICBmaWVsZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFj ZXMuICBPdGhlcndpc2UsIG9ubHkgdGhlDQogICAgICAgICAgICAgICAgbGFz dCAzOSBieXRlcyBzaGFsbCBiZSBpbmNsdWRlZC4NCg0KDQogIG9jdGV0cyA0 MS00ODogIENvbnRhaW5zIGEgZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJl c2VudGF0aW9uIG9mIHRoZQ0KICAgICAgICAgICAgICAgICBqbUpvYkluZGV4 IGFzc2lnbmVkIGJ5IHRoZSBhZ2VudC4gIExlYWRpbmcgemVyb3Mgc2hhbGwN CiAgICAgICAgICAgICAgICAgYmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50 aXJlIDggb2N0ZXQgZmllbGQuDQoNCjEzLjIgIGptSm9iSW5kZXggTWFwcGVk IHRvIFRJUC9TSQ0KDQpqbUpvYkluZGV4IGlzIHJldHVybmVkIHRvIHRoZSBj bGllbnQgYXMgdGhlIFByaW50ZXIgQXNzaWduZWQgSm9iIElkIGluIGENCkpv YiBDb250cm9sLVN0YXJ0IEpvYiAoSkMtU0opIHJlc3BvbnNlIHBhY2tldC4g IFRvIGJlIGNvbXBhdGlibGUgd2l0aA0KdGhlIDE2IGJpdCBmaWVsZCBhbGxv Y2F0ZWQgdG8gdGhpcyB2YWx1ZSBieSBUSVAvU0ksIHRoZSBtYXhpbXVtDQpq bUpvYkluZGV4IGlzIDY1LDUzNS4NCg0KDQoxMy4zICBPdGhlciBNSUIgT2Jq ZWN0cyBNYXBwZWQgdG8gVElQL1NJDQoNCk1JQiBPYmplY3QgICAgICAgICAg ICAgfCBUSVAvU0kgUGFyYW1ldGVyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCmptSm9iT3duZXIgICAgICAgICAgICAgfCBVc2VyIHN0cmluZw0K DQoNCjEzLjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIFRJUC9T SQ0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgfCBUSVAvU0kgaW5mb3JtYXRp b24gICAgICAgICAgICAgIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLQ0Kam9iTmFtZSAgICAgICAgICAgICAgIHwgSm9iIE5hbWUg c3RyaW5nICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iQ29t bWVudCAgICAgICAgICAgIHwgQWRkaXRpb25hbCBJbmZvcm1hdGlvbiBzdHJp bmcgICB8IE9jdGV0IFN0cmluZw0KDQoNCg0KMTQuMCAgUkVGRVJFTkNFUw0K DQpbRFBBXSAgSVNPL0lFQyAxMDE3NS0xOjE5OTYoRSksICJJbmZvcm1hdGlv biB0ZWNobm9sb2d5IC0gVGV4dCBhbmQNCm9mZmljZSBzeXN0ZW1zIC0gRG9j dW1lbnQgUHJpbnRpbmcgQXBwbGljYXRpb24gKERQQSkgLSBQYXJ0IDE6IEFi c3RyYWN0DQpzZXJ2aWNlIGRlZmluaXRpb24gYW5kIHByb2NlZHVyZXMiLCBK VEMxL1NDMTguDQoNCltJUFBdICBUaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJv dG9jb2wgUkZDIFhYWFgsIE1vZGVsIFJGQyBYWFhYDQoNCltJU08tODgyNF0g IElTTy9JRUMgODgyNDoxOTkwLCAiSW5mb3JtYXRpb24gdGVjaG5vbG9neSAt IE9wZW4gU3lzdGVtcw0KSW50ZXJjb25uZWN0aW9uIC0gU3BlY2lmaWNhdGlv biBvZiBBYnN0cmFjdCBTeW50YXggTm90YXRpb24gKEFTTi4xKSIuDQoNCltK b2JNSUJdICBUaGUgSm9iIE1vbml0b3JpbmcgTUlCLCB3b3JrIGluIHByb2dy ZXNzLCA8ZHJhZnQtaWV0Zi0NCnByaW50bWliLWpvYi1tb25pdG9yaW5nLTA3 LnR4dD4sIHRvIGJlIHB1Ymxpc2hlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJG Qw0KYXMgYSBQcmludGVyIFdvcmtpbmcgR3JvdXAgKFBXRykgc3RhbmRhcmQu DQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMjBdDQwNCklO VEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1h cHBpbmcgICAgICAgICBGZWIgMiwgMTk5OA0KDQoNCg0KDQpbTFBEXSAgTGlu ZSBQcmludGVyIERhZW1vbiBQcm90b2NvbCwgUkZDIDExNzksIElFVEYgaW5m b3JtYXRpb25hbA0KZG9jdW1lbnQuDQoNCltQSkxdICBQcmludGVyIEpvYiBM YW5ndWFnZSBUZWNobmljYWwgUmVmZXJlbmNlIE1hbnVhbCwgSGV3bGV0dC1Q YWNrYXJkDQpwYXJ0IG51bWJlciA1MDIxLTAzMjguDQoNCltQcnRNSUJdICBU aGUgUHJpbnRlciBNSUIsIFJGQyAxNzU5LCBJRVRGIHN0YW5kYXJkcyB0cmFj ayBkb2N1bWVudC4NCg0KW1RJUC9TSV0gIElFRUUgU3RhbmRhcmQgMTI4NC4x LCBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgUHJpbnRlci9TeXN0ZW0NCkludGVy ZmFjZS4NCg0KDQoNCjE1LjAgIEFVVEhPUlMNCg0KVGhpcyBkb2N1bWVudCB3 YXMgY3JlYXRlZCB3aXRoIHNpZ25pZmljYW50IGNvbnRyaWJ1dGlvbnMgZnJv bSB0aGUNCmZvbGxvd2luZyBpbmRpdmlkdWFscy4NCg0KICAgIFJvbiBCZXJn bWFuIChFZGl0b3IpDQogICAgRGF0YXByb2R1Y3RzIENvcnAuDQogICAgMTc1 NyBUYXBvIENhbnlvbiBSb2FkDQogICAgU2ltaSBWYWxsZXksIENBIDkzMDYz LTMzOTQNCg0KICAgIFBob25lOiA4MDUtNTc4LTQ0MjENCiAgICBGYXg6ICA4 MDUtNTc4LTQwMDENCiAgICBFbWFpbDogcmJlcmdtYW5AZHBjLmNvbQ0KDQoN CiAgICBUb20gSGFzdGluZ3MNCiAgICBYZXJveCBDb3Jwb3JhdGlvbiwgRVNB RS0yMzENCiAgICA3MDEgUy4gQXZpYXRpb24gQmx2ZC4NCiAgICBFbCBTZWd1 bmRvLCBDQSAgIDkwMjQ1DQoNCiAgICBQaG9uZTogMzEwLTMzMy02NDEzDQog ICAgRmF4OiAgIDMxMC0zMzMtNTUxNA0KICAgIEVNYWlsOiBoYXN0aW5nc0Bj cDEwLmVzLnhlcm94LmNvbQ0KDQoNCiAgICBTY290dCBBLiBJc2FhY3Nvbg0K ICAgIE5vdmVsbCwgSW5jLg0KICAgIDEyMiBFIDE3MDAgUw0KICAgIFByb3Zv LCBVVCAgIDg0NjA2DQoNCiAgICBQaG9uZTogODAxLTg2MS03MzY2DQogICAg RmF4OiAgIDgwMS04NjEtNDAyNQ0KICAgIEVNYWlsOiBzY290dF9pc2FhY3Nv bkBub3ZlbGwuY29tDQoNCg0KICAgIEhhcnJ5IExld2lzDQogICAgSUJNIENv cnBvcmF0aW9uDQogICAgNjMwMCBEaWFnb25hbCBId3kNCiAgICBCb3VsZGVy LCBDTyA4MDMwMQ0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAg IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMjFd DQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3Rv Y29sIE1hcHBpbmcgICAgICAgICBGZWIgMiwgMTk5OA0KDQoNCg0KDQoNCiAg ICBQaG9uZTogKDMwMykgOTI0LTUzMzcNCiAgICBGYXg6ICAgKDMwMykgOTI0 LTQ2NjINCiAgICBFbWFpbDogaGFycnlsQHVzLmlibS5jb20NCg0KDQogICAg Qm9iIFBlbnRlY29zdA0KICAgIEhld2xldHQtUGFja2FyZCBDb3Jwb3JhdGlv bg0KICAgIDExMzExIENoaW5kZW4gQm91bGV2YXJkDQogICAgQm9pc2UsIElE IDgzNzE0DQoNCiAgICBQaG9uZTogKDIwOCkgMzk2LTMzMTINCiAgICBGYXg6 ICAgKDIwOCkgMzk2LTQxMjINCiAgICBFbWFpbDogYnBlbnRlY29AYm9pLmhw LmNvbQ0KDQoNCiAgICBTZW5kIGNvbW1lbnRzIHRvIHRoZSBwcmludG1pYiBX RyB1c2luZyB0aGUgSm9iIE1vbml0b3JpbmcgUHJvamVjdA0KICAgIChKTVAp IE1haWxpbmcgTGlzdDogIGptcEBwd2cub3JnDQoNCiAgICBGb3IgZnVydGhl ciBpbmZvcm1hdGlvbiwgYWNjZXNzIHRoZSBQV0cgd2ViIHBhZ2UgdW5kZXIg IkpNUCI6DQogICAgaHR0cDovL3d3dy5wd2cub3JnLw0KDQoNCk90aGVyIFBh cnRpY2lwYW50czoNCg0KICAgIENodWNrIEFkYW1zIC0gVGVrdHJvbml4DQog ICAgS2VpdGggQ2FydGVyIC0gSUJNIENvcnBvcmF0aW9uDQogICAgQW5nZWxv IENhcnVzbyAtIFhlcm94DQogICAgSmVmZiBDb3BlbGFuZCAtIFFNUw0KICAg IEFuZHkgRGF2aWRzb24gLSBUZWt0cm9uaXgNCiAgICBNYWJyeSBEb3ppZXIg LSBRTVMNCiAgICBMZWUgRmVycmVsIC0gQ2Fub24NCiAgICBEYXZpZCBLZWxs ZXJtYW4gLSBOb3J0aGxha2UgU29mdHdhcmUNCiAgICBSaWNrIExhbmRhdSAt IERpZ2l0YWwNCiAgICBKYXkgTWFydGluIC0gVW5kZXJzY29yZQ0KICAgIEly YSBNY0RvbmFsZCAtIFhlcm94DQogICAgU3R1YXJ0IFJvd2xleSAtIEt5b2Nl cmENCiAgICBCb2IgU2V0dGVyYm8gLSBBZG9iZQ0KICAgIEdhaWwgU29uZ2Vy IC0gRUZJDQogICAgTWlrZSBUaW1wZXJtYW4gLSBMZXhtYXJrDQogICAgV2ls bGlhbSBXYWduZXIgLSBEUEkvT3NpY29tDQogICAgQ2hyaXMgV2VsbGVucyAt IEludGVyd29ya2luZyBMYWJzDQogICAgUm9iIFdoaXR0bGUgLSBOb3ZlbGwN CiAgICBEb24gV3JpZ2h0IC0gTGV4bWFyaw0KICAgIExsb3lkIFlvdW5nIC0g TGV4bWFyaw0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAg ICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAg ICBbcGFnZSAyMl0NDA0KDQo= From rbergma at dpc.com Tue Feb 3 12:39:54 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:14 2009 Subject: JMP> Update to the Protocol Mapping Document - LAST CALL Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> I have updated the Job Submission Protocol Mapping document to include the mapping to IPDS as provided by Harry Lewis. The document can be found at: ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP07.TXT (.DOC) This document should be reviewed very carefully, as I plan to request this revision be considered by the IESG as an Informational RFC. Please try to submit any comments within one week. This is the working group last call for this document. This version has also been submitted to the IETF and will be available as: draft-ietf-printmib-job-protomap-01.txt Watch for the announcement of its availability. Ron Bergman Dataproducts Corp. From rbergma at dpc.com Tue Feb 3 21:45:30 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:14 2009 Subject: JMP> Internet Draft for Job Submission Protocol Mapping Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> KEEgcmVzZW5kIG9mIG15IHN1Ym1pc3Npb24gZnJvbSB0aGlzIG1vcm5pbmcu ICBXZSBkaXNjb3ZlcmVkIHNldmVyYWwNCm9jY3VycmVuY2VzIG9mICJzbWFy dCBxdW90ZXMgaW4gdGhlIGRvY3VtZW50LCB3aGljaCBkbyBub3QgdHJhdmVs IHdlbGwgdmlhDQplbWFpbC4gIFRoZXNlIGhhdmUgYmVlbiByZW1vdmVkIGFu ZCB0aGUgZGF0ZSBhbmQgcmV2aXNpb24gbnVtYmVyIHdlcmUgYWxzbw0KY2hh bmdlZCBzbyB0aGUgdHdvIGRvY3VtZW50cyB3aWxsIG5vdCBiZSBjb25mdXNl ZC4gIFRoZSBlYXJsaWVyIGRyYWZ0IG1heQ0KYmUgZGlzY2FyZGVkLikNCg0K VGhpcyBpcyBhIHN1Ym1pc3Npb24gb2YgdGhlIHRoaXJkIEludGVybmV0LURy YWZ0IG9mIGEgY29tcGFuaW9uIGRvY3VtZW50DQp0byB0aGUgSm9iIE1vbml0 b3JpbmcgTUlCIHRoYXQgcHJvdmlkZXMgYSBtYXBwaW5nIG9mIEpvYiBTdWJt aXNzaW9uDQpQcm90b2NvbHMgdG8gdGhlIEpvYiBNSUI6DQoNCg0KICAgICAg IFRpdGxlICAgICA6IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg UmVjb21tZW5kYXRpb25zIGZvcg0KICAgICAgICAgICAgICAgICAgIHRoZSBK b2IgTW9uaXRvcmluZyBNSUIgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgQXV0aG9yKHMpIDogUi4gQmVyZ21hbg0KICAgICAgIEZpbGVuYW1l ICA6IGRyYWZ0LWlldGYtcHJpbnRtaWItam9iLXByb3RvbWFwLTAyLnR4dA0K ICAgICAgIFBhZ2VzICAgICA6IDIyDQogICAgICAgRGF0ZSAgICAgIDogRmVi cnVhcnkgMywgMTk5OA0KDQoNClRoZSBBYnN0cmFjdCBpczoNCg0KICAgICBU aGlzIEludGVybmV0LURyYWZ0IGRlZmluZXMgdGhlIHJlY29tbWVuZGVkIG1h cHBpbmcgZm9yIG1hbnkNCiAgICAgY3VycmVudGx5IHBvcHVsYXIgSm9iIHN1 Ym1pc3Npb24gcHJvdG9jb2xzIHRvIG9iamVjdHMgYW5kDQogICAgIGF0dHJp YnV0ZXMgdGhlIEpvYiBNb25pdG9yaW5nIE1JQi4NCg0KDQoJVGhhbmsgeW91 LA0KCVJvbiBCZXJnbWFuDQoJRm9yIHRoZSBwcmludG1pYiBXRw0KDQoNCi0t LS0NCg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIEJlcmdtYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIERhdGFwcm9kdWN0cyBDb3JwLg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFy eSAzLCAxOTk4DQoNCg0KICAgICAgICAgICAgIEpvYiBTdWJtaXNzaW9uIFBy b3RvY29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25zDQogICAgICAgICAgICAg ICAgICAgICAgIGZvciB0aGUgSm9iIE1vbml0b3JpbmcgTUlCDQoNCiAgICAg ICAgICAgICAgIDxkcmFmdC1pZXRmLXByaW50bWliLWpvYi1wcm90b21hcC0w Mi50eHQ+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDMsIDE5OTgNCg0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAg ICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0LiAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nDQogICAgIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBh cmVhcywNCiAgICAgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhh dCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgICB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXgNCiAgICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0KICAgICBkb2N1 bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMNCiAgICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQogICAg IHByb2dyZXNzIi4NCg0KICAgICBUbyBsZWFybiB0aGUgY3VycmVudCBzdGF0 dXMgb2YgYW55IEludGVybmV0LURyYWZ0LCBwbGVhc2UgY2hlY2sgdGhlDQog ICAgICIxaWQtYWJzdHJhY3RzLnR4dCIgbGlzdGluZyBjb250YWluZWQgaW4g dGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgICAgRGlyZWN0b3JpZXMg b24gZnRwLmlzLmNvLnphIChBZnJpY2EpLCBuaWMubm9yZHUubmV0IChFdXJv cGUpLA0KICAgICBtdW5uYXJpLm96LmF1IChQYWNpZmljIFJpbSksIGRzLmlu dGVybmljLm5ldCAoVVMgRWFzdCBDb2FzdCksIG9yDQogICAgIGZ0cC5pc2ku ZWR1IChVUyBXZXN0IENvYXN0KS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBYnN0cmFjdA0KDQogICAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgZGVmaW5lcyB0aGUgcmVjb21tZW5kZWQgbWFwcGluZyBmb3IgbWFueQ0K ICAgICBjdXJyZW50bHkgcG9wdWxhciBKb2Igc3VibWlzc2lvbiBwcm90b2Nv bHMgdG8gb2JqZWN0cyBhbmQNCiAgICAgYXR0cmlidXRlcyBpbiB0aGUgSm9i IE1vbml0b3JpbmcgTUlCLg0KDQoNCg0KDQoNCg0KVEFCTEUgT0YgQ09OVEVO VFMNCg0KMS4wICBJTlRST0RVQ1RJT04uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQoyLjAgIExJTkUg UFJJTlRFUiBEQUVNT04gKExQUi9MUEQpIFBST1RPQ09MLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjQNCjIuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFw cGVkIHRvIExQUi9MUEQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NA0KMi4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBMUFIvTFBELi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQoyLjMgIE90aGVyIE1J QiBPYmplY3RzIE1hcHBlZCB0byBMUFIvTFBELi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjUNCjIuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBw ZWQgdG8gTFBELi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDFdDQwNCklOVEVSTkVU LURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg ICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0KDQozLjAgIEFQUExFVEFMSyBQ Uk9UT0NPTC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjYNCjMuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRv IEFwcGxlVGFsay4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KMy4y ICBPdGhlciBBcHBsZVRhbGsgTWFwcGluZ3MuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQo0LjAgIElOVEVSTkVUIFBSSU5U SU5HIFBST1RPQ09MIChJUFApLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjYNCjQuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIElQ UC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0KNC4yICBq bUpvYkluZGV4IE1hcHBlZCB0byBJUFAuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi43DQo0LjMgIE90aGVyIE1JQiBPYmplY3Rz IE1hcHBlZCB0byBJUFAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjcNCjQuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gSVBQ Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOA0KNS4wICBJTlRF TExJR0VOVCBQUklOVEVSIERBVEEgU1RSRUFNIChJUERTKS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi45DQo1LjEgam1Kb2JTdWJtaXNzaW9uSWQgTWFw cGVkIHRvIElQRFMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjkNCjUuMiAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gSVBEUy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KNi4wICBET0NVTUVO VCBQUklOVElORyBBUFBMSUNBVElPTiAoRFBBKS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjEwDQo2LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBl ZCB0byBEUEEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTAN CjYuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gRFBBLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KNi4zICBPdGhlciBNSUIg T2JqZWN0cyBNYXBwZWQgdG8gRFBBLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExDQo2LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVk IHRvIERQQS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTENCjcu MCAgTk9WRUxMIERJU1RSSUJVVEVEIFBSSU5UIFNFUlZJQ0UgKE5EUFMpLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KNy4xICBqbUpvYlN1Ym1pc3Np b25JRCBNYXBwZWQgdG8gTkRQUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjEzDQo3LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIE5EUFMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCjcuMyAg T3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRvIE5EUFMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KNy40ICBUaGUgQXR0cmlidXRlIEdy b3VwIE1hcHBlZCB0byBORFBTLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjE0DQo4LjAgIFBSSU5URVIgSk9CIExBTkdVQUdFIChQSkwpLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCjguMSAgam1K b2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFBKTC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xNQ0KOC4yICBqbUpvYkluZGV4IE1hcHBlZCB0 byBQSkwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjE2DQo4LjMgIE90aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0byBQSkwuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYNCjguNCAgVGhlIEF0 dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gUEpMLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xNg0KOS4wICBQT1NUU0NSSVBULi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2 DQo5LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBQb3N0U2NyaXB0 Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYNCjkuMiAgT3RoZXIgTUlC IE9iamVjdHMgYW5kIEF0dHJpYnV0ZXMgTWFwcGVkIHRvIFBvc3RTY3JpcHQu Li4uLi4uLi4uLi4xNw0KMTAuMCAgTkVUV0FSRSBQU0VSVkVSLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3DQox MC4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gUFNlcnZlci4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcNCjEwLjIgIGptSm9iSW5kZXgg TWFwcGVkIHRvIFBTZXJ2ZXIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xNw0KMTAuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRv IFBKTC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3DQoxMC40 ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQU2VydmVyLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTgNCjExLjAgIE5FVFdBUkUgTlBSSU5U RVIgb3IgUlBSSU5URVIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xOA0KMTIuMCAgU0VSVkVSIE1FU1NBR0UgQkxPQ0sgKFNNQikgUFJP VE9DT0wuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4DQoxMi4xICBq bUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gU01CLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTkNCjEyLjIgIGptSm9iSW5kZXggTWFwcGVk IHRvIFNNQi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xOQ0KMTIuMyAgT3RoZXIgTUlCIG9iamVjdHMgTWFwcGVkIHRvIFNNQi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5DQoxMy4wICBUUkFO U1BPUlQgSU5ERVBFTkRFTlQgUFJJTlRFUi9TWVNURU0gSU5URVJGQUNFIChU SVAvU0kpLi4uLi4uLi4uMTkNCjEzLjEgIGptSm9iU3VibWlzc2lvbklEIE1h cHBlZCB0byBUSVAvU0kuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x OQ0KMTMuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gVElQL1NJLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwDQoxMy4zICBPdGhlciBN SUIgT2JqZWN0cyBNYXBwZWQgdG8gVElQL1NJLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjANCjEzLjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFw cGVkIHRvIFRJUC9TSS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0K MTQuMCAgUkVGRVJFTkNFUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwDQoxNS4wICBBVVRIT1JTLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMjENCg0KDQoNCg0KDQoNCg0KDQoNCkJlcmdtYW4gICAgICAg ICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAg ICAgIFtwYWdlIDJdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJt aXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0K DQoNCg0KDQoxLjAgIElOVFJPRFVDVElPTg0KDQpUaGUgSm9iIE1vbml0b3Jp bmcgTUlCIFtKb2JNSUJdIGlzIGludGVuZGVkIHRvIGJlIGltcGxlbWVudGVk IGluIGENCmRldmljZSBvciBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBhbnkgam9i IHN1Ym1pc3Npb24gcHJvdG9jb2wuICBIb3dldmVyLA0KdGhlIGluZm9ybWF0 aW9uIGF2YWlsYWJsZSBhbmQgdGhlIG1ldGhvZCBvZiBwcmVzZW50YXRpb24g dmFyaWVzDQpzaWduaWZpY2FudGx5IGJ5IGpvYiBzdWJtaXNzaW9uIHByb3Rv Y29sLiAgQSBjb21tb24gbWV0aG9kIG9mIG1hcHBpbmcNCmpvYiBzdWJtaXNz aW9uIGluZm9ybWF0aW9uIHRvIHRoZSBKb2IgTW9uaXRvcmluZyBNSUIgaXMg ZXNzZW50aWFsIGZvcg0KaW50ZXJvcGVyYWJpbGl0eSBvZiBKb2IgTUlCIGFn ZW50cyBhbmQgbW9uaXRvcmluZyBhcHBsaWNhdGlvbnMuICBUaGlzDQpkb2N1 bWVudCBkZWZpbmVzIHJlY29tbWVuZGVkIG1hcHBpbmdzIGZvciBtb3N0IHBv cHVsYXIgam9iIHN1Ym1pc3Npb24NCnByb3RvY29scyB0byBpbnN1cmUgdGhp cyBjb21wYXRpYmlsaXR5Lg0KDQpBbGwgbWFwcGluZ3MgYXJlIHVuaWRpcmVj dGlvbmFsIGZyb20gdGhlIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sIHRvIHRo ZQ0KTUlCLiAgSXQgaXMgYXNzdW1lZCB0aGF0IHN1cHBvcnQgb2YgdGhlIGpv YiBzdWJtaXNzaW9uIHByb3RvY29sIGluIHRoZQ0KcHJpbnRlciBpbXBsaWVz IHRoYXQgdGhlIHJldmVyc2UgaW5mb3JtYXRpb24gZmxvdyBpcyBwcmVzZW50 bHkgZGVmaW5lZA0KYW5kIGRvZXMgbm90IHJlcXVpcmUgaW50ZXJhY3Rpb24g ZnJvbSB0aGUgTUlCLiAgVGhpcyBtYXBwaW5nIGlzIG5vdA0KZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IGFzIGl0IHNob3VsZCBiZSBvYnZpb3VzLg0KDQpU aGlzIGRvY3VtZW50IHJlZmVycyB0byBzeXN0ZW0gY29uZmlndXJhdGlvbnMg dGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUNCkpvYiBNb25pdG9yaW5nIE1JQiBb Sm9iTUlCXS4gIEZvciB0aG9zZSByZWFkZXJzIHRoYXQgYXJlIGZhbWlsaWFy IHdpdGgNCnRoZSBjb25maWd1cmF0aW9uIGRlc2NyaXB0aW9ucywgYSBzaG9y dCBzdW1tYXJ5IGFwcGVhcnMgaGVyZS4gIFBsZWFzZQ0Kc2VlIHRoZSBKb2Ig TUlCIGRvY3VtZW50IGZvciBmdXJ0aGVyIGRldGFpbHMuDQoNCiAgIENvbmZp Z3VyYXRpb24gMTogIFRoaXMgaXMgYSBzaW1wbGUgcGVlci10by1wZWVyIHN5 c3RlbSB3aGljaCBjb250YWlucw0KICAgICAgIG9ubHkgYSBjbGllbnQgYW5k IGEgcHJpbnRlci4gIFRoZSBKb2IgTUlCIGFnZW50IGlzIHJlc2lkZW50IGlu DQogICAgICAgdGhlIHByaW50ZXIuDQoNCiAgIENvbmZpZ3VyYXRpb24gMjog IFRoaXMgc3lzdGVtIGNvbnRhaW5zIGEgY2xpZW50LCBzZXJ2ZXIsIGFuZCBh DQogICAgICAgcHJpbnRlci4gIFRoZSBKaWIgTUlCIGFnZW50IGlzIHJlc2lk ZW50IGluIHRoZSBzZXJ2ZXIuDQoNCiAgIENvbmZpZ3VyYXRpb24gMzogIFRo aXMgc3lzdGVtLCBhcyBpbiBjb25maWd1cmF0aW9uIDIsIGNvbnRhaW5zIGEN CiAgICAgICBjbGllbnQsIHNlcnZlciwgYW5kIGEgcHJpbnRlci4gIEluIHRo aXMgY2FzZSB0aGUgSm9iIE1JQiBhZ2VudCBpcw0KICAgICAgIGltcGxlbWVu dGVkIHdpdGhpbiB0aGUgcHJpbnRlci4NCg0KVGhlIG1vc3QgaW1wb3J0YW50 IG9iamVjdCB0byBiZSBtYXBwZWQgaXMgam1Kb2JTdWJtaXNzaW9uSUQsIHNp bmNlIHRoaXMNCmlzIGEgbWV0aG9kIGZvciB0aGUgdXNlciBvciBjbGllbnQg dG8gZGV0ZXJtaW5lIHRoZSBqbUpvYkluZGV4IGZvciBhDQpzdWJtaXR0ZWQg am9iLiAgVGhlcmVmb3JlLCBqbUpvYlN1Ym1pc3Npb25JRCBpcyBzcGVjaWZp ZWQgZm9yIGFsbCBqb2INCnN1Ym1pc3Npb24gcHJvdG9jb2xzIGRlZmluZWQg aW4gdGhpcyBkb2N1bWVudC4gIFRoZSByZW1haW5pbmcgb2JqZWN0cw0KbWFw cGVkIGluY2x1ZGUgb25seSB0aG9zZSBpdGVtcyB0aGF0IGhhdmUgdGhlIGVx dWl2YWxlbnQgaW5mb3JtYXRpb24NCnByZXNlbnRlZCB0byB0aGUgcHJpbnRl ciBieSB0aGUgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2wuDQoNCldoaWxlIHRo aXMgZG9jdW1lbnQgcGxhY2VzIGEgc3Ryb25nIGVtcGhhc2lzIG9uIGptSm9i U3VibWlzc2lvbklEDQptYXBwaW5nIHRvIG9idGFpbiBqbUpvYkluZGV4LCB0 aGUgcHJlZmVycmVkIG1ldGhvZCBpcyB0aHJvdWdoIHRoZSB1c2Ugb2YNCmEg YmktZGlyZWN0aW9uYWwgcHJvdG9jb2wgdGhhdCByZXR1cm5zIHRoZSB2YWx1 ZSBvZiBqbUpvYkluZGV4IHRvIHRoZQ0KY2xpZW50LCBzdWNoIGFzIElQUC4g IFdoZW4gYSBiaS1kaXJlY3Rpb25hbCBwcm90b2NvbCB0aGF0IHJldHVybnMN CmptSm9iSW5kZXggaXMgaW4gdXNlLCB0aGUgam1Kb2JTdWJtaXNzaW9uSUQg b2JqZWN0IGhhcyBubyB2YWx1ZSB0byB0aGUNCmNsaWVudC4gIFdoZW4gdGhl IGptSm9iSW5kZXggY2Fubm90IGJlIHJldHVybmVkLCB0aGUgdXNlIG9mIGEg Y2xpZW50DQpkZWZpbmVkIGptSm9iU3VibWlzc2lvbklEIGlzIHByZWZlcnJl ZCBvdmVyIGFuIGFnZW50IGRlcml2ZWQgdmFsdWUuICBUaGUNCmNsaWVudCBk ZWZpbmVkIHZlcnNpb24gYWxsb3dzIGZvciByZXRyaWV2YWwgb2Ygam1Kb2JJ bmRleCB1c2luZyBhIHNpbmdsZQ0KU05NUCBHZXQgb3BlcmF0aW9uLCBzaW5j ZSBqbUpvYlN1Ym1pc3Npb25JRCBpcyB0aGUgaW5kZXggaW50byB0aGUNCmpt Sm9iSURUYWJsZS4gIEFuIGFnZW50IGRlcml2ZWQgdmFsdWUgd2lsbCByZXF1 aXJlIGEgc2VhcmNoIHRocm91Z2gNCm11bHRpcGxlIGVudHJpZXMgaW4gdGhl IGptSm9iSURUYWJsZS4NCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgM10NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24g UHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAzLCAxOTk4DQoNCg0KDQoN ClRoZSBtYWpvcml0eSBvZiB0aGUgcHJvdG9jb2xzIG1hcHBlZCBpbiB0aGlz IGRvY3VtZW50IGFyZSBvcmllbnRlZA0KdG93YXJkcyBuZXR3b3JrIGpvYiBz dWJtaXNzaW9uLiAgSG93ZXZlciwgdGhlIEpvYiBNb25pdG9yaW5nIE1JQiBp cyBhbHNvDQppbnRlbmRlZCB0byBtb25pdG9yIHByaW50IGpvYnMgcmVjZWl2 ZWQgZnJvbSBvdGhlciB0aGFuIG5ldHdvcmsgcG9ydHMsDQpzdWNoIGFzIHBh cmFsbGVsIGFuZCBzZXJpYWwgcG9ydHMuICBTb21lIG9mIHRoZSBqb2Igc3Vi bWlzc2lvbiBwcm90b2NvbHMNCmluY2x1ZGVkIHRoYXQgYXJlIHVzZWQgd2l0 aCBub24tbmV0d29ya2VkIHBvcnRzIGFyZSBQSkwsIFBvc3RTY3JpcHQsIGFu ZA0KVElQL1NJLiAgSW4gYWRkaXRpb24sIHRoZSBKb2IgTW9uaXRvcmluZyBN SUIgY2FuIGJlIHVzZWQgd2l0aCBwcmludCBqb2JzDQp0aGF0IGFyZSBpbnRl cm5hbGx5IGdlbmVyYXRlZCwgc3VjaCBhcyBzZWxmIHRlc3QgcGFnZXMuICBJ biB0aGlzIGxhdHRlcg0KY2FzZSwgbm8gbWFwcGluZyBpcyByZXF1aXJlZCBz aW5jZSBhbGwgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2xzIGFyZQ0KYnlwYXNz ZWQuDQoNCg0KDQoyLjAgIExJTkUgUFJJTlRFUiBEQUVNT04gKExQUi9MUEQp IFBST1RPQ09MDQoNClRoZSBMUFIvTFBEIHByaW50aW5nIHByb3RvY29sIFtM UERdIGlzIHVzZWQgd2l0aCBCU0QgVU5JWCBzeXN0ZW1zIGluIHRoZQ0KY2xp ZW50LXNlcnZlci1wcmludGVyIGNvbmZpZ3VyYXRpb24uICBVc2FnZSBvZiB0 aGUgSm9iIE1vbml0b3JpbmcgTUlCDQp3aXRoIExQUi9MUEQgd2lsbCBtb3N0 IGxpa2VseSBjb25mb3JtIHRvIENvbmZpZ3VyYXRpb24gMywgd2hlcmUgdGhl DQptb25pdG9yIGFwcGxpY2F0aW9uIG9yIHRoZSBzZXJ2ZXIgdXNlcyBTTk1Q IHRvIG9idGFpbiBqb2IgaW5mb3JtYXRpb24NCmZyb20gdGhlIHByaW50ZXIu ICBUaGUgY2xpZW50IGNvbW11bmljYXRlcyB3aXRoIHRoZSBVTklYIHNlcnZl ciB1c2luZw0KdGhlIGV4aXN0aW5nIExQRCBwcm90b2NvbCB0byBvYnRhaW4g am9iIGluZm9ybWF0aW9uLg0KDQpUaGUgTFBSL0xQRCBwcm90b2NvbCBpcyBh bHNvIHVzZWQgaW4gdGhlIFdpbmRvd3MgZW52aXJvbm1lbnQgdG8NCmltcGxl bWVudCBwZWVyLXRvLXBlZXIgcHJpbnRpbmcsIGFzIHNob3duIGluIGNvbmZp Z3VyYXRpb24gMS4gIEluIHRoaXMNCmNhc2UsIFNOTVAgaXMgdXNlZCBieSB0 aGUgY2xpZW50IGFuZC9vciB0aGUgbW9uaXRvciBhcHBsaWNhdGlvbiB0bw0K b2J0YWluIHRoZSBqb2IgaW5mb3JtYXRpb24uDQoNCk9uZSBvZiB0aGUgbWFq b3IgcHJvYmxlbXMgb2YgTFBSL0xQRCBpcyB0aGUgbGFyZ2UgbnVtYmVyIG9m IHZlbmRvcg0KdW5pcXVlIGV4dGVuc2lvbnMgY3VycmVudGx5IHVzZWQgd2l0 aCB0aGUgcHJvdG9jb2wgYW5kIHRoZSByZXN1bHRpbmcNCmNvbXBhdGliaWxp dHkgaXNzdWVzIGJldHdlZW4gYXZhaWxhYmxlIGltcGxlbWVudGF0aW9ucy4g IFRvIGF2b2lkIHRoZXNlDQppc3N1ZXMsIHRoaXMgbWFwcGluZyBvZiBMUFIv TFBEIGlzIHJlc3RyaWN0ZWQgdG8gdGhlIHByb3RvY29sIGFzIGRlZmluZWQN CmJ5IFJGQyAxMTc5Lg0KDQpUaGUgTFBSL0xQRCBwcm90b2NvbCB0cmFuc2Zl cnMgcHJpbnQgam9iIGRhdGEgYW5kIGNvbnRyb2wgaW5mb3JtYXRpb24gaW4N CnNlcGFyYXRlIGZpbGVzLCBrbm93biBhcyB0aGUgRGF0YSBGaWxlIGFuZCBD b250cm9sIEZpbGUsIHJlc3BlY3RpdmVseS4NCk1vc3Qgb2YgdGhlIGluZm9y bWF0aW9uIGNvbmNlcm5pbmcgdGhlIHByaW50IGpvYiBpcyBjb250YWluZWQg aW4gdGhlDQpDb250cm9sIEZpbGUuICBJbiBtYW55IExQRCBpbXBsZW1lbnRh dGlvbnMsIHRoZSBDb250cm9sIEZpbGUgaXMNCnRyYW5zZmVycmVkIGZvbGxv d2luZyB0aGUgRGF0YSBGaWxlLiAgVGh1cyBtdWNoIG9mIHRoZSBpbmZvcm1h dGlvbg0KY29uY2VybmluZyB0aGUgam9iIG1heSBub3QgYmUgYXZhaWxhYmxl IHVudGlsIHRoZSBjb21wbGV0aW9uIG9mIHRoZSBkYXRhDQp0cmFuc21pc3Np b24uDQoNCg0KMi4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gTFBS L0xQRA0KDQpUaGUgTFBSL0xQRCBSZWNlaXZlIERhdGEgRmlsZSBjb21tYW5k IGNvbnRhaW5zIGEgcGFyYW1ldGVyIHdoaWNoIGRlZmluZXMNCnRoZSBuYW1l IG9mIHRoZSBkYXRhIGZpbGUuICBUaGlzIG5hbWUgZmllbGQgaXMgc3RydWN0 dXJlZCBhcyBmb2xsb3dzOg0KDQogICAgICAgIGRmYVhYWDxob3N0LW5hbWU+ ICBvciAgZGFYWFhYPGhvc3QtbmFtZT4NCg0KV2hlcmUgWFhYIG9yIFhYWFgg aXMgdGhlIG51bWVyaWMgam9iIG51bWJlciBhc3NpZ25lZCBieSB0aGUgTFBS L0xQRA0KY2xpZW50IHN1Ym1pdHRpbmcgdGhlIHByaW50IGpvYi4gIFRoZSBy ZWNvbW1lbmRlZCBtYXBwaW5nIG9mIHRoaXMgbmFtZQ0KZmllbGQgdG8gam1K b2JTdWJtaXNzaW9uSUQgaXM6DQoNCg0KDQoNCkJlcmdtYW4gICAgICAgICAg ICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAg IFtwYWdlIDRdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNz aW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0KDQoN Cg0KDQogIG9jdGV0IDE6ICAgJzknDQoNCiAgb2N0ZXRzIDItNDA6ICBDb250 YWlucyB0aGUgPGhvc3QtbmFtZT4gcG9ydGlvbiBvZiB0aGUgbmFtZSBmaWVs ZC4gIElmDQogICAgICAgICAgICAgICAgdGhlIDxob3N0LW5hbWU+IHBvcnRp b24gaXMgbGVzcyB0aGFuIDQwIG9jdGV0cywgdGhlDQogICAgICAgICAgICAg ICAgbGVmdC1tb3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5nIHNoYWxsIGFw cGVhciBpbiBvY3RldA0KICAgICAgICAgICAgICAgIHBvc2l0aW9uIDIuICBB bnkgdW51c2VkIHBvcnRpb24gb2YgdGhpcyBmaWVsZCBzaGFsbCBiZQ0KICAg ICAgICAgICAgICAgIGZpbGxlZCB3aXRoIHNwYWNlcy4gIE90aGVyd2lzZSwg b25seSB0aGUgbGFzdCAzOSBieXRlcw0KICAgICAgICAgICAgICAgIHNoYWxs IGJlIGluY2x1ZGVkLg0KDQogIG9jdGV0cyA0MS00ODogICcwMDAwMFhYWCcg b3IgJzAwMDBYWFhYJywgd2hlcmUgWFhYIG9yIFhYWFggaXMgdGhlDQogICAg ICAgICAgICAgICAgIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRh dGlvbiBvZiB0aGUgTFBSL0xQRA0KICAgICAgICAgICAgICAgICBqb2IgbnVt YmVyLg0KDQoNCjIuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gTFBSL0xQRA0K DQpUaGUgam9iIGluZGV4IChqbUpvYkluZGV4KSBpcyBhc3NpZ25lZCBieSB0 aGUgU05NUCBqb2IgbW9uaXRvcmluZyBhZ2VudA0KYW5kIGlzIGluZGVwZW5k ZW50IG9mIHRoZSBYWFggKG9yIFhYWFgpIGluZGV4IGFzc2lnbmVkIGJ5IHRo ZSBMUFIvTFBEDQpjbGllbnQuICBUaGlzIHdpbGwgYWxsb3cgdGhlIFNOTVAg YWdlbnQgdG8gdHJhY2sgam9icyByZWNlaXZlZCBmcm9tDQptdWx0aXBsZSBz b3VyY2VzLg0KDQoNCjIuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRv IExQUi9MUEQNCg0KTUlCIE9iamVjdCAgICAgICAgICAgICAgICAgICAgfCBM UFIvTFBEIFBhcmFtZXRlcg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K am1Kb2JLT2N0ZXRzUGVyQ29weVJlcXVlc3RlZCAgfCBOdW1iZXIgb2YgYnl0 ZXMgYXMgZGVmaW5lZCBpbiB0aGUgRGF0YQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCBGaWxlDQpqbUpvYk93bmVyICAgICAgICAgICAgICAg ICAgICB8IENvbnRyb2wgZmlsZSBjb21tYW5kIGNvZGUgPSBQIChVc2VyIElk KQ0KDQoNCjIuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gTFBE DQoNCk90aGVyIGF0dHJpYnV0ZXMgdGhhdCBhcmUgYXBwbGljYWJsZSwgYnV0 IG5vdCBkZWZpbmVkIGluIHRoaXMgc2VjdGlvbg0Kc3VjaCBhcyBhdHRyaWJ1 dGVzIHRoYXQgbWFwIHRvIGEgdmVuZG9yIHVuaXF1ZSBleHRlbnNpb24sIG1h eSBhbHNvIGJlDQppbmNsdWRlZC4NCg0KTUlCIGF0dHJpYnV0ZSAgICAgICAg IHwgTFBSL0xQRCBpbmZvcm1hdGlvbiAgICAgICAgICAgICB8IERhdGEgdHlw ZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0NCmpvYk5hbWUgICAgICAg ICAgICAgICB8IE5hbWUgb2YgdGhlIGRhdGEgZmlsZSAobm90ZSAxKSAgfCBP Y3RldCBTdHJpbmcNCnF1ZXVlTmFtZVJlcXVlc3RlZCAgICB8IFF1ZXVlIG5h bWUgZnJvbSB0aGUgRGF0YSBGaWxlICAgfCBPY3RldCBTdHJpbmcNCmZpbGVO YW1lICAgICAgICAgICAgICB8IFNvdXJjZSBGaWxlIE5hbWUgKG5vdGVzIDIs IDMpICAgfCBPY3RldCBTdHJpbmcNCmRvY3VtZW50TmFtZSAgICAgICAgICB8 IERvY3VtZW50IHRpdGxlIChub3RlcyAyLCA0KSAgICAgfCBPY3RldCBTdHJp bmcNCg0KIE5vdGVzOg0KIC0tLS0tLQ0KICAxLiBTZWUgc2VjdGlvbiAyLjEg KGptSm9iU3VibWlzc2lvbklEKS4NCiAgMi4gVGhlIGluZm9ybWF0aW9uIGlz IG9wdGlvbmFsIGluIHRoZSBDb250cm9sIEZpbGUuICBUaGUgYXR0cmlidXRl DQogICAgIHNob3VsZCBiZSBpbmNsdWRlZCBpZiBwcmVzZW50IGluIHRoZSBD b250cm9sIEZpbGUuDQogIDMuIENvbnRyb2wgZmlsZSBjb21tYW5kIGNvZGUg PSBOLg0KICA0LiBDb250cm9sIGZpbGUgY29tbWFuZCBjb2RlID0gSi4NCg0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9u YWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgNV0NDA0KSU5URVJORVQt RFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAg ICAgICAgIEZlYiAzLCAxOTk4DQoNCg0KDQoNCg0KDQozLjAgIEFQUExFVEFM SyBQUk9UT0NPTA0KDQpBcHBsZVRhbGsgd2FzIG9yaWdpbmFsbHkgZGV2ZWxv cGVkIGFzIGEgcGVlci10by1wZWVyIG5ldHdvcmsgcHJvdG9jb2wsDQphcyBk ZXNjcmliZWQgaW4gY29uZmlndXJhdGlvbiAxLCBmb3IgdXNlIHdpdGggQXBw bGUgTWFjaW50b3NoIGNvbXB1dGVycy4NClRvZGF5LCBwcmludCBzcG9vbGVy cyBhcmUgYWxzbyBhdmFpbGFibGUgZm9yIHVzZSB3aXRoIE1hY2ludG9zaCBj b21wdXRlcg0KbmV0d29ya3MgdGhhdCBjb25mb3JtIHRvIGNvbmZpZ3VyYXRp b25zIDIvMy4gIEluIGFkZGl0aW9uLCBwcmludGluZyB3aXRoDQp0aGUgQXBw bGVUYWxrIHByb3RvY29sIGlzIHN1cHBvcnRlZCBmcm9tIGJvdGggV2luZG93 cyBOVCBzZXJ2ZXJzIGFuZA0KTm92ZWxsIHNlcnZlcnMgYWxzbyBwZXIgY29u ZmlndXJhdGlvbnMgMi8zLg0KDQpUaGUgQXBwbGVUYWxrIHByb3RvY29sIHBy b3ZpZGVzIHZlcnkgbGl0dGxlIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIHVz ZWQNCndpdGggdGhlIEpvYiBNb25pdG9yaW5nIE1JQi4gIFRoZSBNYWNpbnRv c2ggcHJpbnQgZHJpdmVycyBhcmUgYWJsZSB0bw0KcHJvdmlkZSBpbmZvcm1h dGlvbiBjb25jZXJuaW5nIHRoZSB1c2VyIGFuZCBkb2N1bWVudCBuYW1lIGJ1 dCBpbWJlZCB0aGlzDQppbmZvcm1hdGlvbiBpbiB0aGUgUERMLCB3aGljaCBp cyB0eXBpY2FsbHkgUG9zdFNjcmlwdC4gIFRoZSBwcmVmZXJyZWQNCmptSm9i U3VibWlzc2lvbklEIGlzIGNvbnN0cnVjdGVkIGZyb20gdGhlIGluZm9ybWF0 aW9uIGluIHRoZSBQb3N0U2NyaXB0DQpmaWxlLCBhcyBkZWZpbmVkIGluIHNl Y3Rpb24gOS4wLg0KDQoNCjMuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVk IHRvIEFwcGxlVGFsaw0KDQpBbiBhbHRlcm5hdGl2ZSBqbUpvYlN1Ym1pc3Np b25JRCBtYXkgYmUgY29uc3RydWN0ZWQgZnJvbSB0aGUgQ29ubmVjdGlvbg0K SWRlbnRpZmllciBjb250YWluZWQgaW4gdGhlIEFwcGxlVGFsayBQcmludGVy IEFjY2VzcyBQcm90b2NvbCAoUEFQKQ0KaGVhZGVyLiAgU2luY2UgdGhlIENv bm5lY3Rpb24gSWQgaXMgbm90IHJlYWRpbHkgYXZhaWxhYmxlIGluIGFueSBv ZiB0aGUNCmRlZmluZWQgQXBwbGVUYWxrIGltcGxlbWVudGF0aW9ucywgdGhp cyBhcHByb2FjaCBtYXkgYmUgb2YgbGl0dGxlDQp1dGlsaXR5Lg0KDQogIG9j dGV0IDE6ICAgJ0EnDQoNCiAgb2N0ZXRzIDItNDA6ICBDb250YWlucyB0aGUg QXBwbGVUYWxrIHByaW50ZXIgbmFtZSwgd2l0aCB0aGUgZmlyc3QNCiAgICAg ICAgICAgICAgICBjaGFyYWN0ZXIgb2YgdGhlIG5hbWUgaW4gb2N0ZXQgMi4g IEFwcGxlVGFsayBwcmludGVyDQogICAgICAgICAgICAgICAgbmFtZXMgYXJl IGEgbWF4aW11bSBvZiAzMSBjaGFyYWN0ZXJzLiAgQW55IHVudXNlZA0KICAg ICAgICAgICAgICAgIHBvcnRpb24gb2YgdGhpcyBmaWVsZCBzaGFsbCBiZSBm aWxsZWQgd2l0aCBzcGFjZXMuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgJzAwMDAw WFhYJywgd2hlcmUgJ1hYWCcgaXMgdGhlIGRlY2ltYWwgKEFTQ0lJIGNvZGVk KQ0KICAgICAgICAgICAgICAgICByZXByZXNlbnRhdGlvbiBvZiB0aGUgQ29u bmVjdGlvbiBJZC4NCg0KDQozLjIgIE90aGVyIEFwcGxlVGFsayBNYXBwaW5n cw0KDQpObyBvdGhlciBKb2IgTUlCIG9iamVjdHMgb3IgcGFyYW1ldGVycyBj YW4gYmUgZGVyaXZlZCBmcm9tIGluZm9ybWF0aW9uDQphdmFpbGFibGUgaW4g dGhlIEFwcGxlVGFsayBoZWFkZXJzDQoNCg0KDQo0LjAgIElOVEVSTkVUIFBS SU5USU5HIFBST1RPQ09MIChJUFApDQoNClRoZSBJbnRlcm5ldCBQcmludGlu ZyBQcm90b2NvbCBbSVBQXSBzdXBwb3J0cyBwcmludGluZyB1c2luZyBhbnkg b25lIG9mDQp0aGUgdGhyZWUgcG9zc2libGUgY29uZmlndXJhdGlvbnMuICBG b3IgY29uZmlndXJhdGlvbiAyLCB0aGUgbWFwcGluZw0KZGVmaW5lZCBoZXJl aW4gaXMgcGVyZm9ybWVkIG9uIGFuIGFnZW50IHdpdGhpbiB0aGUgc2VydmVy LiAgT3RoZXJ3aXNlLA0KdGhlIG1hcHBpbmcgaXMgcGVyZm9ybWVkIG9uIGFu IGFnZW50IHdpdGhpbiB0aGUgcHJpbnRlci4NCg0KDQoNCg0KQmVyZ21hbiAg ICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAg ICAgICAgICAgW3BhZ2UgNl0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9i IFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAzLCAx OTk4DQoNCg0KDQoNCg0KNC4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQg dG8gSVBQDQoNCklQUCBjb250YWlucyBhIHJpY2ggc2V0IG9mIHBhcmFtZXRl cnMgd2hpY2ggYWxsb3cgc2V2ZXJhbCBtZXRob2RzIG9mDQpjcmVhdGluZyB0 aGUgam1Kb2JTdWJtaXNzaW9uSUQgb2JqZWN0LiAgVG8gcHJldmVudCBpbnRl cm9wZXJhYmlsaXR5DQpwcm9ibGVtcywgdGhlIHByZWZlcnJlZCBtZXRob2Qg aXMgdG8gdXNlIHRoZSBJUFAgam9iLXVyaSBhdHRyaWJ1dGUgYXMNCmZvbGxv d3M6DQoNCiAgb2N0ZXQgMTogICAnNCcNCg0KICBvY3RldHMgMi00MDogIENv bnRhaW5zIHRoZSBJUFAgam9iLXVyaSBqb2IgZGVzY3JpcHRpb24gYXR0cmli dXRlDQogICAgICAgICAgICAgICAgZ2VuZXJhdGVkIGJ5IHRoZSBwcmludGVy LiAgKFRoZSBqb2ItdXJpIGlzIHJldHVybmVkIHRvDQogICAgICAgICAgICAg ICAgdGhlIGNsaWVudCBieSBJUFAuKSAgSWYgdGhlIGpvYi11cmkgaXMgbGVz cyB0aGFuIDQwDQogICAgICAgICAgICAgICAgb2N0ZXRzLCB0aGUgbGVmdC1t b3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5nIHNoYWxsDQogICAgICAgICAg ICAgICAgYXBwZWFyIGluIG9jdGV0IHBvc2l0aW9uIDIuICBBbnkgdW51c2Vk IHBvcnRpb24gb2YgdGhpcw0KICAgICAgICAgICAgICAgIGZpZWxkIHNoYWxs IGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4gIE90aGVyd2lzZSwgb25seSB0aGUN CiAgICAgICAgICAgICAgICBsYXN0IDM5IGJ5dGVzIHNoYWxsIGJlIGluY2x1 ZGVkLg0KDQogIG9jdGV0cyA0MS00ODogIENvbnRhaW5zIHRoZSBkZWNpbWFs IChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRpb24gb2YNCiAgICAgICAgICAg ICAgICAgdGhlIGpvYi1pZCBqb2IgZGVzY3JpcHRpb24gYXR0cmlidXRlLiAg TGVhZGluZyB6ZXJvcw0KICAgICAgICAgICAgICAgICBzaGFsbCBiZSBpbnNl cnRlZCB0byBmaWxsIHRoZSBlbnRpcmUgOCBvY3RldCBmaWVsZC4NCg0KDQo0 LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIElQUA0KDQpUaGUgam9iIGluZGV4 IChqbUpvYkluZGV4KSBhc3NpZ25lZCBieSB0aGUgU05NUCBqb2IgbW9uaXRv cmluZyBhZ2VudCBpcw0KcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBieSBJUFAg YXMgdGhlIGpvYi1pZCBqb2IgZGVzY3JpcHRpb24gYXR0cmlidXRlLg0KKFNp bmNlIElQUCBkb2VzIG5vdCByZXF1aXJlIGNvbnNlY3V0aXZlbHkgZ2VuZXJh dGVkIGpvYi1pZHMsIHRoZSBhZ2VudA0KbWF5IHJlY2VpdmUgam9icyBmcm9t IG11bHRpcGxlIGNsaWVudHMgYW5kIGNhbiBhc3NpZ24gam1Kb2JJbmRleCBp biBhbg0KYXNjZW5kaW5nIHNlcXVlbmNlIGluZGVwZW5kZW50IG9mIHRoZSBz dWJtaXR0aW5nIGpvYiBjbGllbnQuKSAgVGhlIElQUA0Kam9iLWlkIG11c3Qg YmUgcmVzdHJpY3RlZCB0byB0aGUgcmFuZ2Ugb2YgMSB0byA5OSw5OTksOTk5 IChkZWNpbWFsKSB0bw0KYWxsb3cgdGhlIHZhbHVlIHRvIGJlIHByb3Blcmx5 IHJlcHJlc2VudGVkIGluIGptSm9iU3VibWlzc2lvbklELg0KDQoNCjQuMyAg T3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRvIElQUA0KDQpNSUIgT2JqZWN0 ICAgICAgICAgICAgICAgICAgICAgICB8IElQUCBKb2IgYXR0cmlidXRlDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmptSm9iU3RhdGUgICAgICAgICAg ICAgICAgICAgICAgIHwgam9iLXN0YXRlDQpqbUpvYlN0YXRlUmVhc29uczEg ICAgICAgICAgICAgICB8IGpvYi1zdGF0ZS1yZWFzb25zIChub3RlIDEpDQpq bU51bWJlck9mSW50ZXJ2ZW5pbmdKb2JzICAgICAgICB8IG51bWJlci1vZi1p bnRlcnZlbmluZy1qb2JzDQpqbUpvYktPY3RldHNQZXJDb3B5UmVxdWVzdGVk ICAgICB8IGpvYi1rLW9jdGV0cw0Kam1Kb2JLT2N0ZXRzUHJvY2Vzc2VkICAg ICAgICAgICAgfCBqb2Itay1vY3RldHMtcHJvY2Vzc2VkDQpqbUpvYkltcHJl c3Npb25zUGVyQ29weVJlcXVlc3RlZCB8IGpvYi1pbXByZXNzaW9ucw0Kam1K b2JJbXByZXNzaW9uc0NvbXBsZXRlZCAgICAgICAgfCBqb2ItaW1wcmVzc2lv bnMtY29tcGxldGVkDQpqbUpvYk93bmVyICAgICAgICAgICAgICAgICAgICAg ICB8IGpvYi1vcmlnaW5hdGluZy11c2VyLW5hbWUNCg0KIE5vdGVzOg0KIC0t LS0tLQ0KICAxLiBqbUpvYlN0YXRlUmVhc29uczEgaXMgYSBiaXQgbWFwIGRl c2NyaWJlZCBpbiBvbmUgb2JqZWN0IGFuZCB0aHJlZQ0KICAgICBhdHRyaWJ1 dGVzLiAgVGhlIElQUCBjb25kaXRpb24gbWF5IGNoYW5nZSBvbmUgb3IgbW9y ZSBvZiB0aGUgYml0cw0KICAgICBpbiBvbmUgb3IgbW9yZSBvZiB0aGVzZSBK b2IgTUlCIGl0ZW1zLg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAg ICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2Ug N10NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJv dG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAzLCAxOTk4DQoNCg0KDQoNCg0K DQo0LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIElQUA0KDQpU aGUgZm9sbG93aW5nIG1hcHBpbmdzIGFyZSByZXF1aXJlZCBpZiB0aGUgbGlz dGVkIElQUCBqb2IgdGVtcGxhdGUNCmF0dHJpYnV0ZSBpcyBwcm92aWRlZC4N Cg0KTUlCIGF0dHJpYnV0ZSAgICAgICAgICAgICAgfCBJUFAgam9iIGF0dHJp YnV0ZSAgICAgICAgICAgIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0NCmpvYlN0YXRlUmVhc29uc04gICAgICAgICAgIHwgam9i LXN0YXRlLXJlYXNvbnMgKG5vdGUgMykgICB8IEludGVnZXINCmpvYkNvZGVk Q2hhclNldCAgICAgICAgICAgIHwgYXR0cmlidXRlcy1jaGFyc2V0IChub3Rl IDEpICB8IE9jdGV0IFN0cmluZw0Kam9iTmF0dXJhbExhbmd1YWdlVGFnICAg ICAgfCBhdHRyaWJ1dGVzLW5hdHVyYWwtbGFuZ3VhZ2UgIHwgT2N0ZXQgU3Ry aW5nDQpqb2JVUkkgICAgICAgICAgICAgICAgICAgICB8IGpvYi11cmkgICAg ICAgICAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmpvYk5hbWUgICAg ICAgICAgICAgICAgICAgIHwgam9iLW5hbWUgICAgICAgICAgICAgICAgICAg ICB8IE9jdGV0IFN0cmluZw0KcGh5c2ljYWxEZXZpY2UgICAgICAgICAgICAg fCBvdXRwdXQtZGV2aWNlLWFzc2lnbmVkICAgICAgIHwgT2N0ZXQgU3RyaW5n DQpudW1iZXJPZkRvY3VtZW50cyAgICAgICAgICB8IG51bWJlci1vZi1kb2N1 bWVudHMgICAgICAgICAgfCBJbnRlZ2VyDQpqb2JQcmlvcml0eSAgICAgICAg ICAgICAgICB8IGpvYi1wcmlvcml0eSAgICAgICAgICAgICAgICAgfCBJbnRl Z2VyDQpqb2JIb2xkVW50aWwgICAgICAgICAgICAgICB8IGpvYi1ob2xkLXVu dGlsICAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCnNpZGVzICAgICAg ICAgICAgICAgICAgICAgIHwgc2lkZXMgKG5vdGUgMikgICAgICAgICAgICAg ICB8IEludGVnZXINCmZpbmlzaGluZyAgICAgICAgICAgICAgICAgIHwgZmlu aXNoaW5ncyAgICAgICAgICAgICAgICAgICB8IEludGVnZXINCnByaW50UXVh bGl0eVJlcXVlc3RlZCAgICAgIHwgcHJpbnQtcXVhbGl0eSAgICAgICAgICAg ICAgICB8IEludGVnZXINCnByaW50ZXJSZXNvbHV0aW9uUmVxdWVzdGVkIHwg cHJpbnRlci1yZXNvbHV0aW9uICAgICAgICAgICB8IEludGVnZXINCmpvYkNv cGllc1JlcXVlc3RlZCAgICAgICAgIHwgY29waWVzIChub3RlIDQpICAgICAg ICAgICAgICB8IEludGVnZXINCmRvY3VtZW50Q29waWVzUmVxdWVzdGVkICAg IHwgY29waWVzIChub3RlIDQpICAgICAgICAgICAgICB8IEludGVnZXINCmpv YkNvbGxhdGlvblR5cGUgICAgICAgICAgIHwgbXVsdGlwbGUtZG9jdW1lbnQt aGFuZGxpbmcgICB8IEludGVnZXINCnNoZWV0c1JlcXVlc3RlZCAgICAgICAg ICAgIHwgam9iLW1lZGlhLXNoZWV0cyAgICAgICAgICAgICB8IEludGVnZXIN CnNoZWV0c0NvbXBsZXRlZCAgICAgICAgICAgIHwgam9iLW1lZGlhLXNoZWV0 cy1jb21wbGV0ZWQgICB8IEludGVnZXINCm1lZGl1bVJlcXVlc3RlZCAgICAg ICAgICAgIHwgbWVkaWEgICAgICAgICAgICAgICAgICAgICAgICB8IE9jdGV0 IFN0cmluZw0Kam9iU3VibWlzc2lvblRpbWUgICAgICAgICAgfCB0aW1lLWF0 LXN1Ym1pc3Npb24gICAgICAgICAgIHwgSW50ZWdlcg0Kam9iU3RhcnRlZFBy b2Nlc3NpbmdUaW1lICAgfCB0aW1lLWF0LXByb2Nlc3NpbmcgICAgICAgICAg IHwgSW50ZWdlcg0Kam9iQ29tcGxldGlvblRpbWUgICAgICAgICAgfCB0aW1l LWF0LWNvbXBsZXRlZCAgICAgICAgICAgIHwgSW50ZWdlcg0KDQogTm90ZXM6 DQogLS0tLS0tDQogIDEuIGpvYkNvZGVkQ2hhclNldCBpcyBhbiBlbnVtIGZy b20gdGhlIElBTkEgcmVnaXN0cnkgd2hpY2ggaXMgYWxzbw0KICAgICB1c2Vk IGluIHRoZSBQcmludGVyIE1JQi4gIFRoZSBJUFAgYXR0cmlidXRlcy1jaGFy c2V0IGlzIHRoZSBuYW1lDQogICAgIChNSU1FIHByZWZlcnJlZCBuYW1lKSBv ZiB0aGUgY2hhcmFjdGVyIHNldC4NCiAgMi4gVGhlIEpvYiBNSUIgc2lkZXMg YXR0cmlidXRlIHVzZXMgdGhlIGludGVnZXIgdmFsdWVzICIxIiBhbmQgIjIi Lg0KICAgICBUaGUgSVBQIHNpZGVzIGF0dHJpYnV0ZSB1c2VzIHRocmVlIGtl eXdvcmRzLg0KICAzLiBqb2JTdGF0ZVJlYXNvbnNOIGlzIGEgYml0IG1hcCBk ZXNjcmliZWQgaW4gb25lIG9iamVjdCBhbmQgdGhyZWUNCiAgICAgYXR0cmli dXRlcy4gIFRoZSBJUFAgY29uZGl0aW9uIG1heSBjaGFuZ2Ugb25lIG9yIG1v cmUgb2YgdGhlIGJpdHMNCiAgICAgaW4gb25lIG9yIG1vcmUgb2YgdGhlc2Ug Sm9iIE1JQiBpdGVtcy4NCiAgNC4gVGhlIElQUCAiY29waWVzIiBhdHRyaWJ1 dGUgbWFwcyB0byB0aGUgSm9iIE1JQjoNCiAgICAgKDEpIGpvYkNvcGllc1Jl cXVlc3RlZCB3aGVuIHRoZSBqb2IgaGFzIG9ubHkgb25lIGRvY3VtZW50IE9S DQogICAgICAgICBJUFAgIm11bHRpcGxlLWRvY3VtZW50LWhhbmRsaW5nIiBp cyAnc2luZ2xlLXZhbHVlZCcNCiAgICAgKDIpIGRvY3VtZW50Q29waWVzUmVx dWVzdGVkLCBpbiB3aGljaCBjYXNlIHRoZSBNSUIgdmFsdWUgaXMgdGhlDQog ICAgICAgICB0b3RhbCBudW1iZXIgb2YgZG9jdW1lbnQgY29waWVzIHRoYXQg dGhlIGpvYiB3aWxsIHByb2R1Y2UgYXMgYQ0KICAgICAgICAgd2hvbGUuDQoN Cg0KDQoNCg0KDQoNCkJlcmdtYW4gICAgICAgICAgICAgICAgICAgICBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDhdDQwNCklO VEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1h cHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0KDQo1LjAgIElOVEVM TElHRU5UIFBSSU5URVIgREFUQSBTVFJFQU0gKElQRFMpDQoNClRoZSBJUERT IGRhdGFzdHJlYW0gZmFjaWxpdGF0ZXMgYSBjbG9zZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB0aGUgcHJpbnQNCnN1cGVydmlzb3IgKFByaW50IFNlcnZpY2Vz IEZhY2lsaXR5IC0gUFNGKSBhbmQgdGhlIHByaW50ZXIuIFRoZXJlIGFyZQ0K UFNGIGFwcGxpY2F0aW9ucyBmb3IgVU5JWCwgV2luZG93cywgT1MvMiwgT1Mv NDAwIGFuZCBob3N0IG9wZXJhdGluZw0Kc3lzdGVtcyBzdWNoIGFzIFZNLCBN VlMgYW5kIFZTRS4gVG9nZXRoZXIsIFBTRiBhbmQgSVBEUyByZXByZXNlbnQg YQ0KY29tcGxldGUsIG1hdHVyZSBhbmQgcm9idXN0IGpvYiBtYW5hZ2VtZW50 IGZyYW1ld29yayB3aGljaCBpbmNsdWRlcyBmb250DQphbmQgcmVzb3VyY2Ug bWFuYWdlbWVudCwgcGFnZSBwcm9ncmVzcyB0cmFja2luZywgam9iIGNhbmNl bGxhdGlvbiwNCmNvbXBsZXRlIGVycm9yIHJlY292ZXJ5IGFuZCBlbmQtdXNl ciBub3RpZmljYXRpb24uIEJlY2F1c2UgUFNGIGFuZCB0aGUNCnByaW50ZXIg Y29ycmVzcG9uZCB2aWEgdGhlIHVzZSBvZiBsb2NhbGx5IGFzc2lnbmVkIElE knMsIHRoZXJlIGlzIGENCmxpbWl0ZWQgYW1vdW50IG9mIGNsZWFyIHRleHQg aW5mb3JtYXRpb24gcHJvdmlkZWQgZHVyaW5nIHN1Ym1pc3Npb24gZm9yDQp1 c2UgYnkgdGhlIEpvYiBNSUIuDQoNCg0KNS4xICBqbUpvYlN1Ym1pc3Npb25J ZCBNYXBwZWQgdG8gSVBEUw0KDQpGb3IgSVBEUyBvbiB0aGUgTVZTIG9yIFZT RSBwbGF0Zm9ybToNCg0KICBvY3RldCAxOiAgICdFJw0KDQogIG9jdGV0cyAy LTQwOiAgQ29udGFpbnMgYnl0ZXMgMi0yNyBvZiB0aGUgWE9IIERlZmluZSBH cm91cCBCb3VuZGFyeQ0KICAgICAgICAgICAgICAgIEdyb3VwIElEIHRyaXBs ZXQuIE9jdGV0IHBvc2l0aW9uIDIgbXVzdCBjYXJyeSB0aGUgdmFsdWUNCiAg ICAgICAgICAgICAgICB4JzAxJy5CeXRlcyAyOC00MCBtdXN0IGJlIGZpbGxl ZCB3aXRoIHNwYWNlcy4NCg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlucyBh IGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRhdGlvbiBvZiB0aGUN CiAgICAgICAgICAgICAgICAgam1Kb2JJbmRleCBhc3NpZ25lZCBieSB0aGUg YWdlbnQuICBMZWFkaW5nIHplcm9zIHNoYWxsDQogICAgICAgICAgICAgICAg IGJlIGluc2VydGVkIHRvIGZpbGwgdGhlIGVudGlyZSA4IG9jdGV0IGZpZWxk Lg0KDQoNCkZvciBJUERTIG9uIHRoZSBWTSBwbGF0Zm9ybToNCg0KICBvY3Rl dCAxOiAgICdGJw0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgYnl0ZXMg Mi0zMSBvZiB0aGUgWE9IIERlZmluZSBHcm91cCBCb3VuZGFyeQ0KICAgICAg ICAgICAgICAgIEdyb3VwIElEIHRyaXBsZXQuIE9jdGV0IHBvc2l0aW9uIDIg bXVzdCBjYXJyeSB0aGUgdmFsdWUNCiAgICAgICAgICAgICAgICB4JzAyJy5C eXRlcyAzMi00MCBtdXN0IGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4NCg0KICBv Y3RldHMgNDEtNDg6ICBDb250YWlucyBhIGRlY2ltYWwgKEFTQ0lJIGNvZGVk KSByZXByZXNlbnRhdGlvbiBvZiB0aGUNCiAgICAgICAgICAgICAgICAgam1K b2JJbmRleCBhc3NpZ25lZCBieSB0aGUgYWdlbnQuICBMZWFkaW5nIHplcm9z IHNoYWxsDQogICAgICAgICAgICAgICAgIGJlIGluc2VydGVkIHRvIGZpbGwg dGhlIGVudGlyZSA4IG9jdGV0IGZpZWxkLg0KDQoNCkZvciBJUERTIG9uIHRo ZSBPUy80MDAgcGxhdGZvcm06DQoNCiAgb2N0ZXQgMTogICAnRycNCg0KICBv Y3RldHMgMi00MDogIENvbnRhaW5zIGJ5dGVzIDItMzYgb2YgdGhlIFhPSCBE ZWZpbmUgR3JvdXAgQm91bmRhcnkNCiAgICAgICAgICAgICAgICBHcm91cCBJ RCB0cmlwbGV0LiBPY3RldCBwb3NpdGlvbiAyIG11c3QgY2FycnkgdGhlIHZh bHVlDQogICAgICAgICAgICAgICAgeCcwMycuQnl0ZXMgMzctNDAgbXVzdCBi ZSBmaWxsZWQgd2l0aCBzcGFjZXMuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgQ29u dGFpbnMgYSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRpb24g b2YgdGhlDQogICAgICAgICAgICAgICAgIGptSm9iSW5kZXggYXNzaWduZWQg YnkgdGhlIGFnZW50LiAgTGVhZGluZyB6ZXJvcyBzaGFsbA0KDQoNCg0KQmVy Z21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAg ICAgICAgICAgICAgICAgW3BhZ2UgOV0NDA0KSU5URVJORVQtRFJBRlQgICAg ICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZl YiAzLCAxOTk4DQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgYmUgaW5zZXJ0 ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0ZXQgZmllbGQuDQoNCg0KNS4y ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBJUERTDQoNCkZvciBN VlMvVlNFLg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IElQRFMg WE9IIERHQiBHcm91cCBJRCAgICAgICAgfCBEYXRhIHR5cGUNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9iU291cmNlUGxhdGZvcm1UeXBlICAg ICAgfCBCeXRlIDIgPSB4JzAxJyAgICAgICAgICAgICAgIHwgSW50ZWdlcg0K am9iTmFtZSAgICAgICAgICAgICAgICAgICAgfCBCeXRlcyA0LTExICAgICAg ICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KRm9yIFZNLg0KDQpN SUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IElQRFMgWE9IIERHQiBHcm91 cCBJRCAgICAgICAgfCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLQ0Kam9iU291cmNlUGxhdGZvcm1UeXBlICAgICAgfCBCeXRlIDIg PSB4JzAyJyAgICAgICAgICAgICAgIHwgSW50ZWdlcg0KZmlsZU5hbWUgICAg ICAgICAgICAgICAgICAgfCBCeXRlcyA0LTExICAgICAgICAgICAgICAgICAg IHwgT2N0ZXQgU3RyaW5nDQoNCg0KRm9yIE9TLzQwMC4NCg0KTUlCIGF0dHJp YnV0ZSAgICAgICAgICAgICAgfCBJUERTIFhPSCBER0IgR3JvdXAgSUQgICAg ICAgIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0N CmpvYlNvdXJjZVBsYXRmb3JtVHlwZSAgICAgIHwgQnl0ZSAyID0geCcwMicg ICAgICAgICAgICAgICB8IEludGVnZXINCmZpbGVOYW1lICAgICAgICAgICAg ICAgICAgIHwgQnl0ZXMgMjMtMzIgICAgICAgICAgICAgICAgICB8IE9jdGV0 IFN0cmluZw0Kam9iTmFtZSAgICAgICAgICAgICAgICAgICAgfCBCeXRlcyAz Ny00NiAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KDQo2 LjAgIERPQ1VNRU5UIFBSSU5USU5HIEFQUExJQ0FUSU9OIChEUEEpDQoNClRo ZSBJU08gMTAxNzUgRG9jdW1lbnQgUHJpbnRpbmcgQXBwbGljYXRpb24gKERQ QSkgW0RQQV0gc3VwcG9ydHMNCnByaW50aW5nIHVzaW5nIGFueSBvbmUgb2Yg dGhlIHRocmVlIHBvc3NpYmxlIGNvbmZpZ3VyYXRpb25zLiAgRm9yDQpjb25m aWd1cmF0aW9uIDIsIHRoZSBtYXBwaW5nIGRlZmluZWQgaGVyZWluIGlzIHBl cmZvcm1lZCBvbiBhIHNlcnZlci4NCk90aGVyd2lzZSwgdGhlIG1hcHBpbmcg aXMgcGVyZm9ybWVkIG9uIGFuIGFnZW50IHdpdGhpbiB0aGUgcHJpbnRlci4N Cg0KDQo2LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBEUEENCg0K RFBBIGNvbnRhaW5zIGEgcmljaCBzZXQgb2YgcGFyYW1ldGVycyB3aGljaCBh bGxvdyBzZXZlcmFsIG1ldGhvZHMgb2YNCmNyZWF0aW5nIHRoZSBqbUpvYlN1 Ym1pc3Npb25JRCBvYmplY3QuICBUbyBwcmV2ZW50IGludGVyb3BlcmFiaWxp dHkNCnByb2JsZW1zLCB0aGUgcHJlZmVycmVkIG1ldGhvZCBpcyB0byB1c2Ug dGhlIERQQSBqb2Itb3JpZ2luYXRpbmctdXNlcg0KYXR0cmlidXRlIGFzIGZv bGxvd3M6DQoNCiAgb2N0ZXQgMTogICAnMCcNCg0KICBvY3RldHMgMi00MDog IENvbnRhaW5zIHRoZSBEUEEgam9iLW93bmVyIGF0dHJpYnV0ZQ0KICAgICAg ICAgICAgICAgIHN1cHBsaWVkIGJ5IHRoZSBzdWJtaXR0ZXIuICBJZiB0aGUg am9iLW93bmVyDQogICAgICAgICAgICAgICAgaXMgbGVzcyB0aGFuIDQwIG9j dGV0cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlDQogICAgICAg ICAgICAgICAgc3RyaW5nIHNoYWxsIGFwcGVhciBpbiBvY3RldCBwb3NpdGlv biAyLiAgQW55IHVudXNlZA0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgMTBdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9u IFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0K DQogICAgICAgICAgICAgICAgcG9ydGlvbiBvZiB0aGlzIGZpZWxkIHNoYWxs IGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4NCiAgICAgICAgICAgICAgICBPdGhl cndpc2UsIG9ubHkgdGhlIGxhc3QgMzkgYnl0ZXMgc2hhbGwgYmUgaW5jbHVk ZWQuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgQ29udGFpbnMgYW4gOC1kaWdpdCBz ZXF1ZW50aWFsIGRlY2ltYWwgbnVtYmVyLg0KDQoNCjYuMiAgam1Kb2JJbmRl eCBNYXBwZWQgdG8gRFBBDQoNClRoZSBqb2IgaW5kZXggKGptSm9iSW5kZXgp IGFzc2lnbmVkIGJ5IHRoZSBTTk1QIGpvYiBtb25pdG9yaW5nIGFnZW50IGlz DQpyZXR1cm5lZCB0byB0aGUgY2xpZW50IGJ5IERQQSBhcyBhIGRlY2ltYWwg ZGlnaXQgc3RyaW5nIGFzIHRoZSB2YWx1ZSBvZg0KdGhlIERQQSBqb2ItaWRl bnRpZmllciBhdHRyaWJ1dGUuICAoU2luY2UgRFBBIGRvZXMgbm90IHJlcXVp cmUNCmNvbnNlY3V0aXZlbHkgZ2VuZXJhdGVkIGpvYi1pZGVudGlmaWVycywg dGhlIGFnZW50IG1heSByZWNlaXZlIGpvYnMgZnJvbQ0KbXVsdGlwbGUgY2xp ZW50cyBhbmQgY2FuIGFzc2lnbiB0aGUgam1Kb2JJbmRleCBpbiBhbiBhc2Nl bmRpbmcgc2VxdWVuY2UNCmluZGVwZW5kZW50IG9mIHRoZSBzdWJtaXR0aW5n IGpvYiBjbGllbnQuKSAgVGhlIERQQSBqb2ItaWRlbnRpZmllciBtdXN0DQpi ZSByZXN0cmljdGVkIHRvIHRoZSByYW5nZSBvZiAxIHRvIDk5LDk5OSw5OTkg KGRlY2ltYWwpIHRvIGFsbG93IHRoZQ0KdmFsdWUgdG8gYmUgcHJvcGVybHkg cmVwcmVzZW50ZWQgaW4gam1Kb2JTdWJtaXNzaW9uSUQuDQoNCg0KNi4zICBP dGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gRFBBDQoNCk1JQiBPYmplY3Qg ICAgICAgICAgICAgICAgICAgICAgIHwgRFBBIEpvYiBhdHRyaWJ1dGUNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmptSm9iU3RhdGUgICAgICAgICAg ICAgICAgICAgICAgIHwgam9iLXN0YXRlDQpqbUpvYlN0YXRlUmVhc29uczEg ICAgICAgICAgICAgICB8IGpvYi1zdGF0ZS1yZWFzb25zIChub3RlIDIpDQpq bU51bWJlck9mSW50ZXJ2ZW5pbmdKb2JzICAgICAgICB8IGludGVydmVuaW5n LWpvYnMNCmptSm9iS09jdGV0c1BlckNvcHlSZXF1ZXN0ZWQgICAgIHwgdG90 YWwtam9iLW9jdGV0cyAobm90ZXMgMSwgMykNCmptSm9iS09jdGV0c1Byb2Nl c3NlZCAgICAgICAgICAgIHwgam9iLW9jdGV0cy1jb21wbGV0ZWQgKG5vdGUg MSkNCmptSm9iSW1wcmVzc2lvbnNQZXJDb3B5UmVxdWVzdGVkIHwgam9iLWlt cHJlc3Npb24tY291bnQgKG5vdGUgMykNCmptSm9iSW1wcmVzc2lvbnNDb21w bGV0ZWQgICAgICAgIHwgaW1wcmVzc2lvbnMtY29tcGxldGVkDQpqbUpvYk93 bmVyICAgICAgICAgICAgICAgICAgICAgICB8IGpvYi1vd25lcg0KDQogTm90 ZXM6DQogLS0tLS0tDQogIDEuIGptSm9iS09jdGV0c1BlckNvcHlSZXF1ZXN0 ZWQgYW5kIGptSm9iS09jdGV0c1Byb2Nlc3NlZCBpcyBpbiBLDQogICAgIG9j dGV0cyB3aGlsZSB0aGUgRFBBIGpvYi10b3RhbC1vY3RldHMgYW5kIGpvYi1v Y3RldHMtY29tcGxldGVkIGlzDQogICAgIGluIG9jdGV0cyBhbmQgaXMgNjMt Yml0cyBvZiBzaWduaWZpY2FuY2UuDQogIDIuIGpvYlN0YXRlUmVhc29uc04g aXMgYSBiaXQgbWFwIGRlc2NyaWJlZCBpbiBvbmUgb2JqZWN0IGFuZCB0aHJl ZQ0KICAgICBhdHRyaWJ1dGVzLiAgVGhlIERQQSBjb25kaXRpb24gbWF5IGNo YW5nZSBvbmUgb3IgbW9yZSBvZiB0aGUgYml0cw0KICAgICBpbiBvbmUgb3Ig bW9yZSBvZiB0aGVzZSBKb2IgTUlCIGl0ZW1zLiAgQWxzbyB0aGUgRFBBDQog ICAgIGpvYi1zdGF0ZS1yZWFzb25zIGlzIGEgbXVsdGktdmFsdWVkIGF0dHJp YnV0ZSB3aXRoIGVhY2ggdmFsdWUgYmVpbmcNCiAgICAgYW4gT0JKRUNUIElE RU5USUZJRVIgKE9JRCkuDQogIDMuIERQQSBvY3RldHMgaW5jbHVkZSB0aGUg bXVsdGlwbGljYXRpb24gZmFjdG9yIGR1ZSB0byBqb2IgYW5kDQogICAgIGRv Y3VtZW50IGNvcGllcywgd2hpbGUgdGhlIE1JQiB2YWx1ZXMgZG8gbm90Lg0K DQoNCjYuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gRFBBDQoN ClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlmIHRoZSBs aXN0ZWQgRFBBIGpvYiBhdHRyaWJ1dGUgaXMNCnByb3ZpZGVkLg0KDQoNCg0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9u YWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTFdDQwNCklOVEVSTkVU LURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg ICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0KDQpNSUIgYXR0cmlidXRlICAg ICAgICAgICAgICB8IERQQSBqb2IgYXR0cmlidXRlICAgICAgICAgICAgfElQ UCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9i U3RhdGVSZWFzb25zTiAgICAgICAgICAgfCBqb2Itc3RhdGUtcmVhc29ucyAo bm90ZSAyKSAgIHwgSW50ZWdlcg0Kam9iQ29kZWRDaGFyU2V0ICAgICAgICAg ICAgfCAobm90ZSAxKSAgICAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3Ry aW5nDQpqb2JBY2NvdW50TmFtZSAgICAgICAgICAgICB8IGFjY291bnRpbmct aW5mb3JtYXRpb24gICAgICAgfCBPY3RldCBTdHJpbmcNCmpvYk5hbWUgICAg ICAgICAgICAgICAgICAgIHwgam9iLW5hbWUgICAgICAgICAgICAgICAgICAg ICB8IE9jdGV0IFN0cmluZw0KZGV2aWNlTmFtZVJlcXVlc3RlZCAgICAgICAg fCBwcmludGVyLW5hbWUtcmVxdWVzdGVkICAgICAgIHwgT2N0ZXQgU3RyaW5n DQpwaHlzaWNhbERldmljZSAgICAgICAgICAgICB8IHByaW50ZXJzLWFzc2ln bmVkICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCm51bWJlck9mRG9jdW1l bnRzICAgICAgICAgIHwgbnVtYmVyLW9mLWRvY3VtZW50cyAgICAgICAgICB8 IEludGVnZXINCmZpbGVOYW1lICAgICAgICAgICAgICAgICAgIHwgZmlsZS1u YW1lICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KZG9jdW1l bnROYW1lICAgICAgICAgICAgICAgfCBkb2N1bWVudC1uYW1lICAgICAgICAg ICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JDb21tZW50ICAgICAgICAgICAg ICAgICB8IGpvYi1jb21tZW50ICAgICAgICAgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCmRvY3VtZW50Rm9ybWF0ICAgICAgICAgICAgIHwgZG9jdW1lbnQt Zm9ybWF0ICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iUHJpb3Jp dHkgICAgICAgICAgICAgICAgfCBqb2ItcHJpb3JpdHkgICAgICAgICAgICAg ICAgIHwgSW50ZWdlcg0Kam9iUHJvY2Vzc0FmdGVyRGF0ZUFuZFRpbWUgfCBq b2ItcHJpbnQtYWZ0ZXIgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpv dXRwdXRCaW4gICAgICAgICAgICAgICAgICB8IHJlc3VsdHMtcHJvZmlsZS5v dXRwdXQtYmluICAgfCBPY3RldCBTdHJpbmcNCnNpZGVzICAgICAgICAgICAg ICAgICAgICAgIHwgc2lkZXMgKG5vdGUgMykgICAgICAgICAgICAgICB8IElu dGVnZXINCmZpbmlzaGluZyAgICAgICAgICAgICAgICAgIHwgam9iLWZpbmlz aGluZywgZmluaXNoaW5nICAgICB8IEludGVnZXINCnByaW50UXVhbGl0eVJl cXVlc3RlZCAgICAgIHwgcHJpbnQtcXVhbGl0eSAgICAgICAgICAgICAgICB8 IEludGVnZXINCnByaW50ZXJSZXNvbHV0aW9uUmVxdWVzdGVkIHwgZGVmYXVs dC1wcmludGVyLXJlc29sdXRpb24gICB8IEludGVnZXINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIChub3RlIDQpICAgICAgICAgICAgICAgICAg ICB8DQpqb2JDb3BpZXNSZXF1ZXN0ZWQgICAgICAgICB8IHJlc3VsdHMtcHJv ZmlsZS5qb2ItY29waWVzICAgfCBJbnRlZ2VyDQpqb2JDb3BpZXNDb21wbGV0 ZWQgICAgICAgICB8IGpvYi1jb3BpZXMtY29tcGxldGVkICAgICAgICAgfCBJ bnRlZ2VyDQpkb2N1bWVudENvcGllc1JlcXVlc3RlZCAgICB8IGNvcHktY291 bnQgKG5vdGUgNSkgICAgICAgICAgfCBJbnRlZ2VyDQpkb2N1bWVudENvcGll c0NvbXBsZXRlZCAgICB8IGNvcGllcy1jb21wbGV0ZWQgKG5vdGUgNikgICAg fCBJbnRlZ2VyDQpzaGVldHNSZXF1ZXN0ZWQgICAgICAgICAgICB8IGpvYi1t ZWRpYS1zaGVldC1jb3VudCAgICAgICAgfCBJbnRlZ2VyDQpzaGVldHNDb21w bGV0ZWQgICAgICAgICAgICB8IGpvYi1tZWRpYS1zaGVldHMtY29tcGxldGVk ICAgfCBJbnRlZ2VyDQpwYWdlc1JlcXVlc3RlZCAgICAgICAgICAgICB8IGpv Yi1wYWdlLWNvdW50ICAgICAgICAgICAgICAgfCBJbnRlZ2VyDQpwYWdlc0Nv bXBsZXRlZCAgICAgICAgICAgICB8IHBhZ2VzLWNvbXBsZXRlZCAgICAgICAg ICAgICAgfCBJbnRlZ2VyDQptZWRpdW1SZXF1ZXN0ZWQgICAgICAgICAgICB8 IHBhZ2UtbWVkaWEtc2VsZWN0LCAgICAgICAgICAgfCBPY3RldCBTdHJpbmcN CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIGRlZmF1bHQtbWVkaXVt ICAgICAgICAgICAgICB8DQpqb2JTdWJtaXNzaW9uVGltZSAgICAgICAgICB8 IHN1Ym1pc3Npb24tdGltZSAobm90ZSA3KSAgICAgfCBPY3RldCBTdHJpbmcN CmpvYlN0YXJ0ZWRQcm9jZXNzaW5nVGltZSAgIHwgc3RhcnRlZC1wcmludGlu Zy10aW1lIChub3RlIDcpIE9jdGV0IFN0cmluZw0Kam9iQ29tcGxldGlvblRp bWUgICAgICAgICAgfCBjb21wbGV0aW9uLXRpbWUgKG5vdGUgNykgICAgIHwg T2N0ZXQgU3RyaW5nDQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4gRXZlcnkg RFBBIGF0dHJpYnV0ZSBpcyB0YWdnZWQgaW5kaWNhdGluZyB0aGUgY29kZWQg Y2hhcmFjdGVyIHNldA0KICAgICB0byBiZSB1c2VkIGZvciB0aGF0IGF0dHJp YnV0ZS4NCiAgMi4gam9iU3RhdGVSZWFzb25zTiBpcyBhIGJpdCBtYXAgZGVz Y3JpYmVkIGluIG9uZSBvYmplY3QgYW5kIHRocmVlDQogICAgIGF0dHJpYnV0 ZXMuICBUaGUgRFBBIGNvbmRpdGlvbiBtYXkgY2hhbmdlIG9uZSBvciBtb3Jl IG9mIHRoZSBiaXRzDQogICAgIGluIG9uZSBvciBtb3JlIG9mIHRoZXNlIEpv YiBNSUIgaXRlbXMuICBBbHNvIHRoZSBEUEENCiAgICAgam9iLXN0YXRlLXJl YXNvbnMgaXMgYSBtdWx0aS12YWx1ZWQgYXR0cmlidXRlIHdpdGggZWFjaCB2 YWx1ZSBiZWluZw0KICAgICBhbiBPQkpFQ1QgSURFTlRJRklFUiAoT0lEKS4N CiAgMy4gVGhlIEpvYiBNSUIgc2lkZXMgYXR0cmlidXRlIGlzIGFuIGludGVn ZXIgJzEnIG9yICcyJyB3aGlsZSB0aGUgRFBBDQogICAgIHNpZGVzIGF0dHJp YnV0ZSBoYXMgb25lIG9mIHNpeCBPSUQgdmFsdWVzIHRoYXQgaW5jbHVkZXMg cGxleC4NCiAgNC4gcHJpbnRlclJlc29sdXRpb25SZXF1ZXN0ZWQgaGFzIHgg YW5kIHkgcmVzb2x1dGlvbiBhbmQgaXMgaW50ZW5kZWQNCiAgICAgdG8gb3Zl cnJpZGUgdGhlIHJlc29sdXRpb24gaW5zdHJ1Y3Rpb24gaW4gdGhlIGRvY3Vt ZW50LCBpZiBhbnksDQogICAgIHdoaWxlIHRoZSBEUEEgZGVmYXVsdC1wcmlu dGVyLXJlc29sdXRpb24gaXMgdGhlIHNhbWUgaW4geCBhbmQgeSBhbmQNCiAg ICAgb25seSB0YWtlcyBlZmZlY3QgaWYgdGhlIGRvY3VtZW50IGRvZXMgbm90 IGNvbnRhaW4gYSByZXNvbHV0aW9uDQogICAgIGluc3RydWN0aW9uDQogIDUu IFRoZSBEUEEgImNvcHktY291bnQiIGF0dHJpYnV0ZSBpcyBhIHBlci1kb2N1 bWVudCBhdHRyaWJ1dGUsIHNvIHRoZQ0KDQoNCg0KQmVyZ21hbiAgICAgICAg ICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAg ICAgW3BhZ2UgMTJdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJt aXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0K DQoNCg0KDQogICAgIE1JQiB2YWx1ZSBpcyB0aGUgc3VtIG9mIHRoZSBkb2N1 bWVudHMnICJjb3B5LWNvdW50IiB2YWx1ZXMgdGltZXMNCiAgICAgdGhlIGpv YidzICJyZXN1bHRzLXByb2ZpbGUuam9iLWNvcGllcyIgdmFsdWUuDQogIDYu IFRoZSBEUEEgImNvcGllcy1jb21wbGV0ZWQiIGF0dHJpYnV0ZSBpcyBhIHBl ci1kb2N1bWVudCBhdHRyaWJ1dGUsDQogICAgIHNvIHRoZSBNSUIgdmFsdWUg aXMgdGhlIHN1bSBvZiB0aGUgZG9jdW1lbnRzJyAiY29waWVzLWNvbXBsZXRl ZCINCiAgICAgdmFsdWVzIHRpbWVzIHRoZSBqb2IncyAicmVzdWx0cy1wcm9m aWxlLmpvYi1jb3BpZXMiIHZhbHVlLg0KICA3LiBUaGUgRFBBIEdlbmVyYXRs aXplZFRpbWUgZGF0YSB0eXBlIGlzIGRlZmluZWQgYnkgSVNPIDg4MjQNCiAg ICAgKElTTy04ODI0KSB3aGlsZSB0aGUgTUlCIERhdGVBbmRUaW1lIGlzIGRl ZmluZWQgYnkgU05NUHYyLVRDLg0KDQoNCg0KNy4wICBOT1ZFTEwgRElTVFJJ QlVURUQgUFJJTlQgU0VSVklDRSAoTkRQUykNCg0KTm92ZWxsIERpc3RyaWJ1 dGVkIFByaW50IFNlcnZpY2VzIGlzIGEgRFBBIGJhc2VkIGpvYiBzdWJtaXNz aW9uIHByb3RvY29sDQp0aGF0IGNvbmZvcm1zIHRvIGNvbmZpZ3VyYXRpb24g My4NCg0KDQo3LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBORFBT DQoNCk5EUFMgc3VwcG9ydHMgdGhlIGdlbmVyYXRpb24gb2YgYSBwcm9wZXJs eSBmb3JtYXR0ZWQgam1Kb2JTdWJtaXNzaW9uSUQNCmZvciB1c2UgaW4gdGhl IEpvYiBNSUIsIHZpYSB0aGUgYXR0cmlidXRlIG5kcHMtYXR0LWpvYi1pZGVu dGlmaWVyLg0KDQpJU1NVRTogSXMgdGhpcyB0aGUgcHJvcGVyIE5EUFMgYXR0 cmlidXRlIG9yIHNob3VsZCB0aGUgYXR0cmlidXRlIG5kcHMtDQphdHQtaWRl bnRpZmllci1vbi1jbGllbnQgb3IgbmRwcy1hdHQtbmV3LWpvYi1pZGVudGlm aWVyIHRvIGJlIHVzZWQ/DQoNCg0KNy4yICBqbUpvYkluZGV4IE1hcHBlZCB0 byBORFBTDQoNCk5EUFMgZGVmaW5lcyB0aGUgYXR0cmlidXRlIG5kcHMtYXR0 LWpvYi1pZGVudGlmaWVyLW9uLXByaW50ZXIgdGhhdCBjYW4NCmJlIHVzZWQg dG8gcmV0dXJuIHRoZSB2YWx1ZSBvZiBqbUpvYkluZGV4IHRvIHRoZSBORFBT IGNsaWVudC4NCg0KDQo3LjMgIE90aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0 byBORFBTDQoNCk1JQiBPYmplY3QgICAgICAgICAgICAgICAgICAgICAgIHwg TkRQUyBQYXJhbWV0ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K am1Kb2JTdGF0ZSAgICAgICAgICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1j dXJyZW50LWpvYi1zdGF0ZSAobm90ZSAxKQ0Kam1Kb2JTdGF0ZVJlYXNvbnMx ICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2Itc3RhdGUtcmVhc29ucyAo bm90ZSAyKQ0Kam1OdW1iZXJPZkludGVydmVuaW5nSm9icyAgICAgICAgfCBu ZHBzLWF0dC1pbnRlcnZlbmluZy1qb2JzDQpqbUpvYktPY3RldHNQZXJDb3B5 UmVxdWVzdGVkICAgICB8IG5kcHMtYXR0LXRvdGFsLWpvYi1vY3RldHMgKG5v dGVzIDMsNCkNCmptSm9iS09jdGV0c1Byb2Nlc3NlZCAgICAgICAgICAgIHwg bmRwcy1hdHQtb2N0ZXRzLWNvbXBsZXRlZCAobm90ZSAzKQ0Kam1Kb2JJbXBy ZXNzaW9uc1BlckNvcHlSZXF1ZXN0ZWQgfCBuZHBzLWF0dC1qb2ItaW1wcmVz c2lvbnMtY291bnQNCmptSm9iSW1wcmVzc2lvbnNDb21wbGV0ZWQgICAgICAg IHwgbmRwcy1hdHQtaW1wcmVzc2lvbnMtY29tcGxldGVkDQpqbUpvYk93bmVy ICAgICAgICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LWpvYi1vd25lciAo bm90ZSA1KQ0KDQogTm90ZXM6DQogLS0tLS0tDQogIDEuIFNvbWUgb2YgdGhl IE5EUFMgam9iIHN0YXRlcyBtdXN0IGJlIHJlcHJlc2VudGVkIGJ5IGJvdGgg YQ0KICAgICBqbUpvYlN0YXRlIGFuZCBhIGptSm9iU3RhdGVSZWFzb25zMSBv YmplY3Qgb3IgYSBqb2JTdGF0ZVJlYXNvbnNODQogICAgIGF0dHJpYnV0ZS4N CiAgMi4gVGhlIE5EUFMgam9iIHN0YXRlIHJlYXNvbnMgbWF5IGJlIG1hcHBl ZCB0byBlaXRoZXIgdGhlIG9iamVjdA0KICAgICBqbUpvYlN0YXRlUmVhc29u czEgb3IgdGhlIGF0dHJpYnV0ZSBqb2JTdGF0ZVJlYXNvbnNOLg0KICAzLiBq bUpvYktPY3RldHNQZXJDb3B5UmVxdWVzdGVkIGFuZCBqbUpvYktPY3RldHNQ cm9jZXNzZWQgaXMgaW4gSw0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgMTNdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9u IFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0K DQogICAgIG9jdGV0cyB3aGlsZSB0aGUgTkRQUyBuZHBzLWF0dC1qb2ItdG90 YWwtb2N0ZXRzIGFuZA0KICAgICBuZHBzLWF0dC1qb2Itb2N0ZXRzLWNvbXBs ZXRlZCBpcyBpbiBvY3RldHMgYW5kIGlzIDYzLWJpdHMgb2YNCiAgICAgc2ln bmlmaWNhbmNlLg0KICA0LiBORFBTIG9jdGV0cyBpbmNsdWRlIHRoZSBtdWx0 aXBsaWNhdGlvbiBmYWN0b3IgZHVlIHRvIGpvYiBhbmQNCiAgICAgZG9jdW1l bnQgY29waWVzLCB3aGlsZSB0aGUgTUlCIHZhbHVlcyBkbyBub3QuDQogIDUu IFRoZSBKb2IgTUlCIG9iamVjdCBtdXN0IGJlIG11bHRpcGxpZWQgYnkgdGhl IGF0dHJpYnV0ZQ0KICAgICBqb2JDb3BpZXNSZXF1ZXN0ZWQgdG8gb2J0YWlu IHRoZSBORFBTIGF0dHJpYnV0ZSB2YWx1ZSwgaWYgbXVsdGlwbGUNCiAgICAg Y29waWVzIGhhdmUgYmVlbiByZXF1ZXN0ZWQuDQoNCg0KNy40ICBUaGUgQXR0 cmlidXRlIEdyb3VwIE1hcHBlZCB0byBORFBTDQoNClRoZSBmb2xsb3dpbmcg bWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlmIHRoZSBsaXN0ZWQgUEpMIGF0dHJp YnV0ZSBvcg0KY29tbWFuZCBvcHRpb24gaXMgcHJvdmlkZWQuDQoNCk1JQiBh dHRyaWJ1dGUgICAgICAgICAgICAgIHwgTkRQUyBwYXJhbWV0ZXIgICAgICAg ICAgICAgICB8IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tDQpqb2JBY2NvdW50TmFtZSAgICAgICAgICAgICB8IG5kcHMtYXR0LWpv Yi1vd25lciAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmpvYk5hbWUgICAg ICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQtam9iLW5hbWUgICAgICAgICAg ICB8IE9jdGV0IFN0cmluZw0Kam9iT3JpZ2luYXRpbmdIb3N0ICAgICAgICAg fCBuZHBzLWF0dC1qb2Itb3JpZ2luYXRvciAgICAgIHwgT2N0ZXQgU3RyaW5n DQpkZXZpY2VOYW1lUmVxdWVzdGVkICAgICAgICB8IG5kcHMtYXR0LXByaW50 ZXItbmFtZS0tICAgICAgfCBPY3RldCBTdHJpbmcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgcmVxdWVzdGVkICAgICAgICAgICB8 DQpudW1iZXJPZkRvY3VtZW50cyAgICAgICAgICB8IG5kcHMtYXR0LW51bWJl ci1vZi1kb2N1bWVudHMgfCBJbnRlZ2VyDQpmaWxlTmFtZSAgICAgICAgICAg ICAgICAgICB8IG5kcHMtYXR0LWRvY3VtZW50LWZpbGUtbmFtZSAgfCBPY3Rl dCBTdHJpbmcNCmRvY3VtZW50TmFtZSAgICAgICAgICAgICAgIHwgbmRwcy1h dHQtZG9jdW1lbnQtbmFtZSAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iQ29t bWVudCAgICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2ItY29tbWVudCAg ICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpkb2N1bWVudEZvcm1hdEluZGV4ICAg ICAgICB8IG5kcHMtYXR0LXBydEludGVycHJldGVySW5kZXggfCBJbnRlZ2Vy DQpkb2N1bWVudEZvcm1hdCAgICAgICAgICAgICB8IG5kcHMtYXR0LWRvY3Vt ZW50LWZvcm1hdCAgICAgfCBJbnRlZ2VyDQpqb2JQcmlvcml0eSAgICAgICAg ICAgICAgICB8IG5kcHMtYXR0LWpvYi1wcmlvcml0eSAgICAgICAgfCBJbnRl Z2VyDQpqb2JQcm9jZXNzQWZ0ZXJEYXRlQW5kVGltZSB8IG5kcHMtYXR0LWpv Yi1wcmludC1hZnRlciAgICAgfCBPY3RldCBTdHJpbmcNCm91dHB1dEJpbiAg ICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQtcmVzdWx0cy1wcm9maWxlICAg ICB8IEludGVnZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChu b3RlIDEpICAgICAgICAgICAgICAgICAgICB8DQpzaWRlcyAgICAgICAgICAg ICAgICAgICAgICB8IG5kcHMtYXR0LXNpZGVzIChub3RlIDIpICAgICAgfCBJ bnRlZ2VyDQpmaW5pc2hpbmcgICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0 LWpvYi1maW5pc2hpbmcgICAgICAgfCBJbnRlZ2VyDQpwcmludFF1YWxpdHlS ZXF1ZXN0ZWQgICAgICB8IG5kcHMtYXR0LXByaW50LXF1YWxpdHkgICAgICAg fCBJbnRlZ2VyDQpwcmludGVyUmVzb2x1dGlvblJlcXVlc3RlZCB8IG5kcHMt YXR0LWRlZmF1bHQtcHJpbnRlci0tICAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgcmVzb2x1dGlvbiAobm90ZSAzKSAgICAgICAgIHwgSW50 ZWdlcg0KcHJpbnRlclJlc29sdXRpb25Vc2VkICAgICAgfCBuZHBzLWF0dC1k ZWZhdWx0LXJlc29sdXRpb25zLS0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIHVzZWQgICAgICAgICAgICAgICAgICAgICAgICB8IEludGVnZXIN CmpvYkNvcGllc1JlcXVlc3RlZCAgICAgICAgIHwgbmRwcy1hdHQtcmVzdWx0 cy1wcm9maWxlICAgICB8IEludGVnZXINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgIChub3RlIDQpICAgICAgICAgICAgICAgICAgICB8DQpqb2JD b3BpZXNDb21wbGV0ZWQgICAgICAgICB8IG5kcHMtYXR0LWpvYi1jb3BpZXMt Y29tcGxldGVkfCBJbnRlZ2VyDQpkb2N1bWVudENvcGllc1JlcXVlc3RlZCAg ICB8IG5kcHMtYXR0LWNvcHktY291bnQgICAgICAgICAgfCBJbnRlZ2VyDQpk b2N1bWVudENvcGllc0NvbXBsZXRlZCAgICB8IG5kcHMtYXR0LWNvcGllcy1j b21wbGV0ZWQgICAgfCBJbnRlZ2VyDQogICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAobm90ZSAzKQ0Kc2hlZXRzUmVxdWVzdGVkICAgICAgICAgICAg fCBuZHBzLWF0dC1qb2ItbWVkaWEtLSAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICBzaGVldC1jb3Vu dCB8IEludGVnZXINCnNoZWV0c0NvbXBsZXRlZCAgICAgICAgICAgIHwgbmRw cy1hdHQtbWVkaWEtc2hlZXRzLS0gICAgICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICBjb21wbGV0ZWQgfCBJ bnRlZ2VyDQptZWRpdW1Db25zdW1lZCAgICAgICAgICAgICB8IG5kcHMtYXR0 LW1lZGlhLXVzZWQgICAgICAgICAgfCBJbnRlZ2VyDQpqb2JTdWJtaXNzaW9u VG9TZXJ2ZXJUaW1lICB8IG5kcHMtYXR0LXN1Ym1pc3Npb24tdGltZSAgICAg fCBPY3RldCBTdHJpbmcNCmpvYlN1Ym1pc3Npb25UaW1lICAgICAgICAgIHwg bmRwcy1hdHQtc3RhcnRlZC1wcmludGluZy10aW1lIE9jdGV0IFN0cmluZw0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9u YWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTRdDQwNCklOVEVSTkVU LURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg ICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0KDQpqb2JDb21wbGV0aW9uVGlt ZSAgICAgICAgICB8IG5kcHMtYXR0LWNvbXBsZXRpb24tdGltZSAgICAgfCBP Y3RldCBTdHJpbmcNCg0KIE5vdGVzOg0KIC0tLS0tLQ0KICAxLiBUaGUgb3V0 cHV0LWJpbiBmaWVsZCBpbiBuZHBzLWF0dC1yZXN1bHRzLXByb2ZpbGUgaXMg dG8gYmUgdXNlZC4NCiAgMi4gVGhlIEpvYiBNSUIgc2lkZXMgYXR0cmlidXRl IGlzIGFuIGludGVnZXIgJzEnIG9yICcyJyB3aGlsZSB0aGUgTkRQUw0KICAg ICBzaWRlcyBhdHRyaWJ1dGUgaGFzIG9uZSBvZiBzaXggT0lEIHZhbHVlcyB0 aGF0IGluY2x1ZGVzIHBsZXguDQogIDMuIHByaW50ZXJSZXNvbHV0aW9uUmVx dWVzdGVkIGhhcyB4IGFuZCB5IHJlc29sdXRpb24gYW5kIGlzIGludGVuZGVk DQogICAgIHRvIG92ZXJyaWRlIHRoZSByZXNvbHV0aW9uIGluc3RydWN0aW9u IGluIHRoZSBkb2N1bWVudCwgaWYgYW55LA0KICAgICB3aGlsZSB0aGUgbmRw cy1hdHQtZGVmYXVsdC1wcmludGVyLXJlc29sdXRpb24gaXMgdGhlIHNhbWUg aW4geCBhbmQNCiAgICAgeSBhbmQgb25seSB0YWtlcyBlZmZlY3QgaWYgdGhl IGRvY3VtZW50IGRvZXMgbm90IGNvbnRhaW4gYQ0KICAgICByZXNvbHV0aW9u IGluc3RydWN0aW9uDQogIDQuIFRoZSBqb2ItY29waWVzIGZpZWxkIGluIG5k cHMtYXR0LXJlc3VsdHMtcHJvZmlsZSBpcyB0byBiZSB1c2VkLg0KDQoNCg0K OC4wICBQUklOVEVSIEpPQiBMQU5HVUFHRSAoUEpMKQ0KDQpQSkwgW1BKTF0g aGFzIGJlZW4gZGV2ZWxvcGVkIGJ5IEhld2xldHQtUGFja2FyZCB0byBwcm92 aWRlIGpvYiBjb250cm9sDQppbmZvcm1hdGlvbiB0byB0aGUgcHJpbnRlciBh bmQgc3RhdHVzIGluZm9ybWF0aW9uIHRvIGFwcGxpY2F0aW9ucywNCmluZGVw ZW5kZW50IG9mIHRoZSBQREwuDQoNCg0KOC4xICBqbUpvYlN1Ym1pc3Npb25J RCBNYXBwZWQgdG8gUEpMDQoNClBKTCBoYXMgZGVmaW5lZCB0aGUgU1VCTUlT U0lPTklEIG9wdGlvbiBmb3IgdGhlIEpPQiBjb21tYW5kIHdoaWNoDQppbmRp Y2F0ZXMgYSBwcm9wZXJseSBmb3JtYXR0ZWQgam1Kb2JTdWJtaXNzaW9uSUQg Zm9yIHVzZSBpbiB0aGUgSm9iIE1JQi4NClRoZSBQSkwgSk9CIGNvbW1hbmQg aXMgcHJlc2VudGVkIGF0IHRoZSBzdGFydCBvZiBhIHByaW50IGpvYiB3aXRo DQpvcHRpb25zIHRoYXQgYXBwbHkgb25seSB0aGUgYXR0YWNoZWQgam9iLiAg VGhlIHN5bnRheCBmb3IgdGhpcyBjb21tYW5kDQpvcHRpb24gaXM6DQoNCiAg ICAgIEBQSkwgSk9CIFNVQk1JU1NJT05JRCA9ICJpZCBzdHJpbmciDQoNCkRy aXZlciBzb2Z0d2FyZSB0aGF0IGltcGxlbWVudHMgdGhpcyBQSkwgY29tbWFu ZCBvcHRpb24gbXVzdCBwcm92aWRlIHRoZQ0KImlkIHN0cmluZyIgaW4gb25l IG9mIHRoZSBjbGllbnQgdmVyc2lvbiBmb3JtYXRzIHNwZWNpZmllZCBpbiB0 aGUgSm9iDQpNSUIgZm9yIGptSm9iU3VibWlzc2lvbklELg0KDQpGb3IgZHJp dmVycyB0aGF0IGFyZSBub3QgYWJsZSB0byBjcmVhdGUgdGhlIFNVQk1JU1NJ T05JRCBvcHRpb24sIGl0IGlzDQpyZWNvbW1lbmRlZCB0aGF0IGptSm9iU3Vi bWlzc2lvbklEIGZvcm1hdCAwIGJlIGNyZWF0ZWQgYnkgdGhlIGFnZW50DQp1 c2luZyB0aGUgUEpMIGF0dHJpYnV0ZSBEb2NPd25lciBvciBEb2NPd25lcklk Lg0KDQogIG9jdGV0IDE6ICAgJzAnDQoNCiAgb2N0ZXRzIDItNDA6ICBDb250 YWlucyB0aGUgc3RyaW5nIGFzc29jaWF0ZWQgd2l0aCBEb2NPd25lciBvcg0K ICAgICAgICAgICAgICAgIERvY093bmVySWQuICBJZiB0aGUgc3RyaW5nIGlz IGxlc3MgdGhhbiA0MCBvY3RldHMsIHRoZQ0KICAgICAgICAgICAgICAgIGxl ZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmluZyBzaGFsbCBhcHBlYXIg aW4gb2N0ZXQNCiAgICAgICAgICAgICAgICBwb3NpdGlvbiAyLiAgT3RoZXJ3 aXNlLCBvbmx5IHRoZSBsYXN0IDM5IGJ5dGVzIHNoYWxsIGJlDQogICAgICAg ICAgICAgICAgaW5jbHVkZWQuICBBbnkgdW51c2VkIHBvcnRpb24gb2YgdGhp cyBmaWVsZCBzaGFsbCBiZQ0KICAgICAgICAgICAgICAgIGZpbGxlZCB3aXRo IHNwYWNlcy4gIElmIERvY093bmVyIG9yIERvY093bmVySWQgY2Fubm90IGJl DQogICAgICAgICAgICAgICAgb2J0YWluZWQsIHRoaXMgZmllbGQgc2hhbGwg YmUgYmxhbmsuDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAg ICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2Ug MTVdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFBy b3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0KDQog IG9jdGV0cyA0MS00ODogIENvbnRhaW5zIHRoZSB2YWx1ZSBvZiBqbUpvYklu ZGV4IGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgICAgICAgICAgICAgICAgam9i LiAgTGVhZGluZyB6ZXJvcyBzaGFsbCBiZSBpbnNlcnRlZCB0byBmaWxsIHRo ZQ0KICAgICAgICAgICAgICAgICBlbnRpcmUgOCBvY3RldCBmaWVsZC4NCg0K DQo4LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFBKTA0KDQpQSkwgZG9lcyBu b3QgcHJvdmlkZSBhIHZhbHVlIHRoYXQgY2FuIGJlIG1hcHBlZCB0byBqbUpv YkluZGV4Lg0KDQoNCjguMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRv IFBKTA0KDQpNSUIgT2JqZWN0ICAgICAgICAgICAgfCBQSkwgSm9iIGF0dHJp YnV0ZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpvYk93bmVyICAgICAgICAgICAgICB8 IERvY093bmVyIG9yIERvY093bmVySWQgYXR0cmlidXRlDQoNCg0KOC40ICBU aGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQSkwNCg0KVGhlIGZvbGxv d2luZyBtYXBwaW5ncyBhcmUgcmVxdWlyZWQgaWYgdGhlIGxpc3RlZCBQSkwg YXR0cmlidXRlIG9yDQpjb21tYW5kIG9wdGlvbiBpcyBwcm92aWRlZC4NCg0K TUlCIGF0dHJpYnV0ZSAgICAgICAgIHwgUEpMIGF0dHJpYnV0ZSBvciBjb21t YW5kIG9wdGlvbiAgfCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLQ0Kc2VydmVyQXNzaWduZWRKb2JOYW1lIHwgRG9jTmFtZSBhdHRy aWJ1dGUgb3IgdGhlIGNvbW1hbmQgfCBPY3RldCBTdHJpbmcNCiAgICAgICAg ICAgICAgICAgICAgICB8ICBAUEpMIEpPQiBOYW1lID0gInN0cmluZyIgICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpzdWJtaXR0aW5nU2VydmVyTmFtZSAgfCBT cmNTZXJ2ZXJOYW1lIGF0dHJpYnV0ZSAgICAgICAgICB8IE9jdGV0IFN0cmlu Zw0Kam9iT3JpZ2luYXRpbmdIb3N0ICAgIHwgU3JjUG9ydCBhdHRyaWJ1dGUg ICAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCnF1ZXVlTmFtZVJlcXVl c3RlZCAgICB8IFNyY1EgYXR0cmlidXRlICAgICAgICAgICAgICAgICAgIHwg T2N0ZXQgU3RyaW5nDQpmaWxlTmFtZSAgICAgICAgICAgICAgfCBKb2JGTmFt ZSBhdHRyaWJ1dGUgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9i Q29tbWVudCAgICAgICAgICAgIHwgSm9iRGVzYyBhdHRyaWJ1dGUgICAgICAg ICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmpvYlN1Ym1pc3Npb25UaW1lICAg ICB8IFRpbWVTdWJtaXQgYXR0cmlidXRlICAgICAgICAgICAgIHwgT2N0ZXQg U3RyaW5nDQoNCg0KDQo5LjAgIFBPU1RTQ1JJUFQNCg0KVGhlIFBvc3RTY3Jp cHQgUERMIHBlcm1pdHMgY29tbWVudCBmaWVsZHMgd2hpY2ggY2FuIGJlIHVz ZWQgYnkNCmFwcGxpY2F0aW9uIGRyaXZlcnMgdG8gaW5jbHVkZSBqb2IgaW5m b3JtYXRpb24uICBBbHRob3VnaCB0aGVyZSBhcmUgbm8NCnJlc3RyaWN0aW9u cyBvciByZXF1aXJlbWVudHMgYXMgdG8gd2hhdCBpbmZvcm1hdGlvbiBtYXkg YmUgaW5jbHVkZWQsDQptYW55IGRyaXZlcnMgaW5jbHVkZSBqb2Igb3duZXIg YW5kL29yIGRvY3VtZW50IG5hbWUuDQoNCg0KOS4xICBqbUpvYlN1Ym1pc3Np b25JRCBNYXBwZWQgdG8gUG9zdFNjcmlwdA0KDQpUaGUgdXNlIG9mIGEgc3Rh bmRhcmQgZm9ybWF0IGpvYiBzdWJtaXNzaW9uIGlkIGNvbW1lbnQgc3RyaW5n IHdpbGwgYWxsb3cNCmludGVyb3BlcmFiaWxpdHkgb2YgcHJpbnRlcnMgYW5k IGRyaXZlcnMgZnJvbSBtdWx0aXBsZSB2ZW5kb3JzLiAgVGhlDQpmb2xsb3dp bmcgY29tbWVudCBzdHJpbmcgZm9ybWF0IGlzIHJlY29tbWVuZGVkIGZvciB1 c2Ugd2l0aCBQb3N0U2NyaXB0DQpsZXZlbCAxIGFuZCBsZXZlbCAyIGRhdGEg c3RyZWFtcy4NCg0KICAgICAlJUpNUEpvYlN1Ym1pc3Npb25JZDooaWQtc3Ry aW5nKQ0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5m b3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAxNl0NDA0K SU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wg TWFwcGluZyAgICAgICAgIEZlYiAzLCAxOTk4DQoNCg0KDQoNCndoZXJlICJp ZCBzdHJpbmciIGNhbiBiZSBhbnkgam1Kb2JTdWJtaXNzaW9uSUQgZm9ybWF0 IHJlc2VydmVkIGZvcg0KY2xpZW50cy4NCg0KOS4yICBPdGhlciBNSUIgT2Jq ZWN0cyBhbmQgQXR0cmlidXRlcyBNYXBwZWQgdG8gUG9zdFNjcmlwdA0KDQpO byBPdGhlciBtYXBwaW5ncyBmcm9tIFBvc3RTY3JpcHQgY29tbWVudCBzdHJp bmdzIGFyZSByZWNvbW1lbmRlZCwgYnV0DQptYW55IEpvYiBNSUIgb2JqZWN0 cyBhbmQgYXR0cmlidXRlcyBjYW4gYmUgZGVmaW5lZCB1c2luZyB2ZW5kb3Ig dW5pcXVlDQpjb21tZW50IHN0cmluZ3MuDQoNCg0KDQoxMC4wICBORVRXQVJF IFBTRVJWRVINCg0KVGhlIE5ldFdhcmUgUFNlcnZlciBqb2Igc3VibWlzc2lv biBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBpbiBhIGNsaWVudC0NCnNlcnZl ci1wcmludGVyIHN5c3RlbSBvbiB0aGUgc2VydmVyIHRvIHByaW50ZXIgbGlu ayBhcyBkZWZpbmVkIGluDQpjb25maWd1cmF0aW9uIDMuDQoNCg0KMTAuMSAg am1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFBTZXJ2ZXINCg0KICBvY3Rl dCAxOiAgICdCJw0KDQoNCiAgb2N0ZXRzIDItNDA6ICBDb250YWlucyB0aGUg RGlyZWN0b3J5IFBhdGggTmFtZSBvZiB0aGUgYWdlbnQgYXMNCiAgICAgICAg ICAgICAgICByZWNvcmRlZCBieSB0aGUgTm92ZWxsIEZpbGUgU2VydmVyIGlu IHRoZSBxdWV1ZQ0KICAgICAgICAgICAgICAgIGRpcmVjdG9yeS4gIElmIHRo ZSBzdHJpbmcgaXMgbGVzcyB0aGFuIDQwIG9jdGV0cywgdGhlDQogICAgICAg ICAgICAgICAgbGVmdC1tb3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5nIHNo YWxsIGFwcGVhciBpbiBvY3RldA0KICAgICAgICAgICAgICAgIHBvc2l0aW9u IDIuICBPdGhlcndpc2UsIG9ubHkgdGhlIGxhc3QgMzkgYnl0ZXMgc2hhbGwg YmUNCiAgICAgICAgICAgICAgICBpbmNsdWRlZC4gIEFueSB1bnVzZWQgcG9y dGlvbiBvZiB0aGlzIGZpZWxkIHNoYWxsIGJlDQogICAgICAgICAgICAgICAg ZmlsbGVkIHdpdGggc3BhY2VzLg0KDQogIG9jdGV0cyA0MS00ODogICcwMDBY WFhYWCcgIFRoZSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRp b24gb2YNCiAgICAgICAgICAgICAgICAgdGhlIEpvYiBOdW1iZXIgYXMgcGVy IHRoZSBOZXRXYXJlIEZpbGUgU2VydmVyIFF1ZXVlDQogICAgICAgICAgICAg ICAgIE1hbmFnZW1lbnQgU2VydmljZXMuDQoNCg0KMTAuMiAgam1Kb2JJbmRl eCBNYXBwZWQgdG8gUFNlcnZlcg0KDQpUaGUgam9iIGluZGV4IChqbUpvYklu ZGV4KSBpcyBhc3NpZ25lZCBieSB0aGUgU05NUCBqb2IgbW9uaXRvcmluZyBh Z2VudA0KYW5kIGlzIGluZGVwZW5kZW50IG9mIHRoZSBKb2IgTnVtYmVyIGFz c2lnbmVkIGJ5IHRoZSBOZXRXYXJlIEZpbGUgU2VydmVyDQpRdWV1ZSBNYW5h Z2VtZW50IFNlcnZpY2VzLiAgVGhpcyB3aWxsIGFsbG93IHRoZSBTTk1QIGFn ZW50IHRvIHRyYWNrIGpvYnMNCnJlY2VpdmVkIGZyb20gbXVsdGlwbGUgc291 cmNlcy4NCg0KDQoxMC4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8g UEpMDQoNCk1JQiBPYmplY3QgICAgICAgICAgICB8IFBTZXJ2ZXIgSm9iIGF0 dHJpYnV0ZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpvYk93bmVyICAgICAgICAgICAg ICB8IENsaWVudCBJZCBOdW1iZXIgICAgICAgICAgICB8IE9jdGV0IFN0cmlu Zw0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTddDQwN CklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29s IE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0KDQoNCg0KDQoxMC40ICBU aGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQU2VydmVyDQoNClRoZSBm b2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlmIHRoZSBsaXN0ZWQg UFNlcnZlciBwYXJhbWV0ZXIgaXMNCnByb3ZpZGVkIGluIHRoZSBOb3ZlbGwg RmlsZSBTZXJ2ZXIgcXVldWUgZGlyZWN0b3J5Lg0KDQpNSUIgYXR0cmlidXRl ICAgICAgICAgICAgICB8IFBTZXJ2ZXIgcGFyYW1ldGVyICAgICAgICAgICB8 IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tDQpzZXJ2 ZXJBc3NpZ25lZEpvYk5hbWUgICAgICB8IEpvYiBGaWxlIE5hbWUgICAgICAg ICAgICAgICB8IE9jdGV0IFN0cmluZw0KcXVldWVOYW1lUmVxdWVzdGVkICAg ICAgICAgfCBRdWV1ZSBJZCAgICAgICAgICAgICAgICAgICAgfCBJbnRlZ2Vy DQpwaHlzaWNhbERldmljZSAgICAgICAgICAgICB8IFNlcnZlciBJZCBOdW1i ZXIgICAgICAgICAgICB8IEludGVnZXINCmpvYkNvbW1lbnQgICAgICAgICAg ICAgICAgIHwgSm9iIERlc2NyaXB0aW9uICAgICAgICAgICAgIHwgT2N0ZXQg U3RyaW5nDQpqb2JQcmlvcml0eSAgICAgICAgICAgICAgICB8IChub3RlIDEp ICAgICAgICAgICAgICAgICAgICB8IEludGVnZXINCmpvYlByb2Nlc3NBZnRl ckRhdGVBbmRUaW1lIHwgVGFyZ2V0IEV4ZWN1dGlvbiBUaW1lICAgICAgIHwg T2N0ZXQgU3RyaW5nDQpqb2JDb3BpZXNSZXF1ZXN0ZWQgICAgICAgICB8IE51 bWJlciBvZiBDb3BpZXMgICAgICAgICAgICB8IEludGVnZXINCm1lZGl1bVJl cXVlc3RlZCAgICAgICAgICAgIHwgRm9ybSBOYW1lICAgICAgICAgICAgICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdWJtaXNzaW9uVG9TZXJ2ZXJUaW1l ICB8IEpvYiBFbnRyeSBUaW1lICAgICAgICAgICAgICB8IE9jdGV0IFN0cmlu Zw0KDQpOb3RlczoNCi0tLS0tLQ0KIDEuIFRoZSBqb2IgcHJpb3JpdHkgaXMg ZGV0ZXJtaW5lZCBieSB0aGUgcHJpb3JpdHkgYXNzaWduZWQgdG8gdGhlIHF1 ZXVlDQogICAgdGhhdCBjb250YWlucyB0aGUgam9iLiAgRWFjaCBxdWV1ZSBj YW4gYmUgYXNzaWduZWQgYSB1bmlxdWUgcHJpb3JpdHkNCiAgICBhbmQgdGhl IHByaW9yaXR5IG9mIHRoZSBqb2IgaXMgaW5oZXJpdGVkIGZyb20gdGhlIHF1 ZXVlLg0KDQoNCg0KMTEuMCAgTkVUV0FSRSBOUFJJTlRFUiBvciBSUFJJTlRF Ug0KDQpUaGUgTmV0V2FyZSBOUHJpbnRlci9SUHJpbnRlciBwcm90b2NvbCB3 YXMgZGVzaWduZWQgdG8gdHJhbnNmZXIgcHJpbnQNCmRhdGEgZnJvbSBhIE5v dmVsbCBGaWxlIFNlcnZlciB0byBhIHByaW50ZXIgYXR0YWNoZWQgZGlyZWN0 bHkgdG8gYSBsb2NhbA0KcG9ydCAoZS5nLiBwYXJhbGxlbCBvciBzZXJpYWwp IG9uIGEgUEMuICBOUHJpbnRlci9SUHJpbnRlciBpcyBhbg0KZXh0cmVtZWx5 IGxpZ2h0d2VpZ2h0IHByaW50aW5nIHByb3RvY29sLiAgQ29uc2VxdWVudGx5 LCBubyBpbmZvcm1hdGlvbg0KcmVxdWlyZWQgYnkgdGhlIEpvYiBNb25pdG9y aW5nIE1JQiBpcyBwcm92aWRlZCBhbmQgYSBtZWFuaW5nZnVsDQpqbUpvYlN1 Ym1pc3Npb25JRCBjYW5ub3QgYmUgZ2VuZXJhdGVkLg0KDQpJdCBpcyByZWNv bW1lbmRlZCB0aGF0IGFuIGFkZGl0aW9uYWwgam9iIHN1Ym1pc3Npb24gbGF5 ZXIsIHN1Y2ggYXMgUEpMDQpvciBhbm90aGVyIHZlbmRvciBwcml2YXRlIHBy b3RvY29sLCAgYmUgaW5jbHVkZWQgb24gdG9wIG9mDQpOUHJpbnRlci9SUHJp bnRlciB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbi4gIFRo ZSBtYXBwaW5nDQpzaG91bGQgdGhlbiBiZSBwZXJmb3JtZWQgYWNjb3JkaW5n IHRvIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgdGhlIGhpZ2hlcg0KbGF5ZXIg c3VibWlzc2lvbiBwcm90b2NvbC4NCg0KDQoNCjEyLjAgIFNFUlZFUiBNRVNT QUdFIEJMT0NLIChTTUIpIFBST1RPQ09MDQoNClRoZSBTZXJ2ZXIgTWVzc2Fn ZSBCbG9jayBwcm90b2NvbCBpcyB1c2VkIHdpdGggc2V2ZXJhbCBQQyBOZXR3 b3JrDQpvcGVyYXRpbmcgc3lzdGVtcywgc3VjaCBhcyBNaWNyb3NvZnQgV2lu ZG93cyBmb3IgV29ya2dyb3VwcywgSUJNIExBTg0KU2VydmVyLCBhbmQgQXJ0 aXNvZnQgTGFudGFzdGljLiAgU01CIHN5c3RlbXMgc3VwcG9ydGluZyB0aGUg Sm9iDQpNb25pdG9yaW5nIE1JQiB3aWxsIGNvbmZvcm0gdG8gZWl0aGVyIGNv bmZpZ3VyYXRpb24gMSBvciAzLg0KDQoNCg0KDQoNCg0KDQpCZXJnbWFuICAg ICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAg ICAgICAgICBbcGFnZSAxOF0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9i IFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiAzLCAx OTk4DQoNCg0KDQoNCjEyLjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0 byBTTUINCg0KICBvY3RldCAxOiAgICdDJw0KDQogIG9jdGV0cyAyLTQwOiAg Q29udGFpbnMgYSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRp b24gb2YgdGhlDQogICAgICAgICAgICAgICAgMTYgYml0IFNNQiBUcmVlIElk IGZpZWxkLCB3aGljaCB1bmlxdWVseSBpZGVudGlmaWVzIHRoZQ0KICAgICAg ICAgICAgICAgIGNvbm5lY3Rpb24gdGhhdCBzdWJtaXR0ZWQgdGhlIGpvYiB0 byB0aGUgcHJpbnRlci4gIFRoZQ0KICAgICAgICAgICAgICAgIG1vc3Qgc2ln bmlmaWNhbnQgZGlnaXQgb2YgdGhlIG51bWVyaWMgc3RyaW5nIHNoYWxsIGJl DQogICAgICAgICAgICAgICAgcGxhY2VkIGluIG9jdGV0IHBvc2l0aW9uIDIu ICBBbGwgdW51c2VkIHBvcnRpb25zIG9mIHRoaXMNCiAgICAgICAgICAgICAg ICBmaWVsZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuICBUaGUgU01C IFRyZWUgSWQgaGFzDQogICAgICAgICAgICAgICAgYSBtYXhpbXVtIHZhbHVl IG9mIDY1LDUzNS4NCg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlucyBhIGRl Y2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRhdGlvbiBvZiB0aGUNCiAg ICAgICAgICAgICAgICAgRmlsZSBIYW5kbGUgcmV0dXJuZWQgZnJvbSB0aGUg cHJpbnRlciBhZ2VudCB0byB0aGUNCiAgICAgICAgICAgICAgICAgY2xpZW50 IGluIHJlc3BvbnNlIHRvIGEgQ3JlYXRlIFByaW50IEZpbGUgY29tbWFuZC4N CiAgICAgICAgICAgICAgICAgTGVhZGluZyB6ZXJvcyBzaGFsbCBiZSBpbnNl cnRlZCB0byBmaWxsIHRoZSBlbnRpcmUgOA0KICAgICAgICAgICAgICAgICBv Y3RldCBmaWVsZC4NCg0KDQoxMi4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBT TUINCg0KSXQgaXMgc3Ryb25nbHkgcmVjb21tZW5kZWQgdGhhdCB0aGUgRmls ZSBIYW5kbGUgcmV0dXJuZWQgZnJvbSB0aGUNCnByaW50ZXIgYWdlbnQgYmUg aWRlbnRpY2FsIHRvIGptSm9iSW5kZXguICBJZiB0aGVzZSBpdGVtcyBhcmUg aWRlbnRpY2FsLA0KdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIGNsaWVudCBh cHBsaWNhdGlvbiB0byBwZXJmb3JtIGEgc2VhcmNoIG9uDQpqbUpvYlN1Ym1p c3Npb25JRC4gIFRvIGJlIGNvbXBhdGlibGUgd2l0aCB0aGUgMTYgYml0IGZp ZWxkIGFsbG9jYXRlZCB0bw0KdGhpcyB2YWx1ZSBieSBTTUIsIHRoZSBtYXhp bXVtIGptSm9iSW5kZXggaXMgNjUsNTM1Lg0KDQoNCjEyLjMgIE90aGVyIE1J QiBvYmplY3RzIE1hcHBlZCB0byBTTUINCg0KTUlCIE9iamVjdCAgICAgIHwg U01CIFBhcmFtZXRlcg0KLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmptSm9iT3du ZXIgICAgICB8IFNNQiBVc2VyIElkIGZpZWxkIChub3RlIDEpDQoNCk5vdGVz Og0KLS0tLS0tDQogMS4gQSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVz ZW50YXRpb24gb2YgdGhlIFNNQiBVc2VyIElkIG51bWVyaWMNCiAgICBzaGFs bCBiZSBwcmVzZW50ZWQgYXMgam1Kb2JPd25lci4NCg0KDQoNCjEzLjAgIFRS QU5TUE9SVCBJTkRFUEVOREVOVCBQUklOVEVSL1NZU1RFTSBJTlRFUkZBQ0Ug KFRJUC9TSSkNCg0KVGhlIFRJUC9TSSBwcm90b2NvbCwgYWx0aG91Z2ggY3Vy cmVudGx5IHNwZWNpZmllZCBhcyBhIHBhcnQgb2YgdGhlIElFRUUNCjEyODQg cGFyYWxsZWwgcG9ydCBzdGFuZGFyZHMgW1RJUC9TSV0sIHdhcyBvcmlnaW5h bGx5IGRldmVsb3BlZCBhcyBhDQpuZXR3b3JrIHByb3RvY29sLiAgVElQL1NJ IHRodXMgaGFzIHRoZSBwb3RlbnRpYWwgb2YgYmVpbmcgaW50ZWdyYXRlZA0K aW50byBhbnkgbmV0d29yayBvciBub24tbmV0d29yayBjb25maWd1cmF0aW9u Lg0KDQoxMy4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gVElQL1NJ DQoNCiAgb2N0ZXQgMTogICAnRCcNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAg ICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAg ICAgW3BhZ2UgMTldDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJt aXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgMywgMTk5OA0K DQoNCg0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIEpvYiBOYW1l IGZyb20gdGhlIEpvYiBDb250cm9sLVN0YXJ0IEpvYg0KICAgICAgICAgICAg ICAgIChKQy1TSikgY29tbWFuZC4gIElmIHRoZSBKb2IgTmFtZSBwb3J0aW9u IGlzIGxlc3MgdGhhbg0KICAgICAgICAgICAgICAgIDQwIG9jdGV0cywgdGhl IGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmluZyBzaGFsbA0KICAg ICAgICAgICAgICAgIGFwcGVhciBpbiBvY3RldCBwb3NpdGlvbiAyLiAgQW55 IHVudXNlZCBwb3J0aW9uIG9mIHRoaXMNCiAgICAgICAgICAgICAgICBmaWVs ZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuICBPdGhlcndpc2UsIG9u bHkgdGhlDQogICAgICAgICAgICAgICAgbGFzdCAzOSBieXRlcyBzaGFsbCBi ZSBpbmNsdWRlZC4NCg0KDQogIG9jdGV0cyA0MS00ODogIENvbnRhaW5zIGEg ZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0K ICAgICAgICAgICAgICAgICBqbUpvYkluZGV4IGFzc2lnbmVkIGJ5IHRoZSBh Z2VudC4gIExlYWRpbmcgemVyb3Mgc2hhbGwNCiAgICAgICAgICAgICAgICAg YmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0ZXQgZmllbGQu DQoNCjEzLjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFRJUC9TSQ0KDQpqbUpv YkluZGV4IGlzIHJldHVybmVkIHRvIHRoZSBjbGllbnQgYXMgdGhlIFByaW50 ZXIgQXNzaWduZWQgSm9iIElkIGluIGENCkpvYiBDb250cm9sLVN0YXJ0IEpv YiAoSkMtU0opIHJlc3BvbnNlIHBhY2tldC4gIFRvIGJlIGNvbXBhdGlibGUg d2l0aA0KdGhlIDE2IGJpdCBmaWVsZCBhbGxvY2F0ZWQgdG8gdGhpcyB2YWx1 ZSBieSBUSVAvU0ksIHRoZSBtYXhpbXVtDQpqbUpvYkluZGV4IGlzIDY1LDUz NS4NCg0KDQoxMy4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gVElQ L1NJDQoNCk1JQiBPYmplY3QgICAgICAgICAgICAgfCBUSVAvU0kgUGFyYW1l dGVyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmptSm9iT3duZXIg ICAgICAgICAgICAgfCBVc2VyIHN0cmluZw0KDQoNCjEzLjQgIFRoZSBBdHRy aWJ1dGUgR3JvdXAgTWFwcGVkIHRvIFRJUC9TSQ0KDQpNSUIgYXR0cmlidXRl ICAgICAgICAgfCBUSVAvU0kgaW5mb3JtYXRpb24gICAgICAgICAgICAgIHwg RGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLQ0Kam9iTmFt ZSAgICAgICAgICAgICAgIHwgSm9iIE5hbWUgc3RyaW5nICAgICAgICAgICAg ICAgICB8IE9jdGV0IFN0cmluZw0Kam9iQ29tbWVudCAgICAgICAgICAgIHwg QWRkaXRpb25hbCBJbmZvcm1hdGlvbiBzdHJpbmcgICB8IE9jdGV0IFN0cmlu Zw0KDQoNCg0KMTQuMCAgUkVGRVJFTkNFUw0KDQpbRFBBXSAgSVNPL0lFQyAx MDE3NS0xOjE5OTYoRSksICJJbmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0gVGV4 dCBhbmQNCm9mZmljZSBzeXN0ZW1zIC0gRG9jdW1lbnQgUHJpbnRpbmcgQXBw bGljYXRpb24gKERQQSkgLSBQYXJ0IDE6IEFic3RyYWN0DQpzZXJ2aWNlIGRl ZmluaXRpb24gYW5kIHByb2NlZHVyZXMiLCBKVEMxL1NDMTguDQoNCltJUFBd ICBUaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wgUkZDIFhYWFgsIE1v ZGVsIFJGQyBYWFhYDQoNCltJU08tODgyNF0gIElTTy9JRUMgODgyNDoxOTkw LCAiSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtIE9wZW4gU3lzdGVtcw0KSW50 ZXJjb25uZWN0aW9uIC0gU3BlY2lmaWNhdGlvbiBvZiBBYnN0cmFjdCBTeW50 YXggTm90YXRpb24gKEFTTi4xKSIuDQoNCltKb2JNSUJdICBUaGUgSm9iIE1v bml0b3JpbmcgTUlCLCB3b3JrIGluIHByb2dyZXNzLCA8ZHJhZnQtaWV0Zi0N CnByaW50bWliLWpvYi1tb25pdG9yaW5nLTA3LnR4dD4sIHRvIGJlIHB1Ymxp c2hlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KYXMgYSBQcmludGVyIFdv cmtpbmcgR3JvdXAgKFBXRykgc3RhbmRhcmQuDQoNCg0KDQoNCg0KQmVyZ21h biAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAg ICAgICAgICAgICAgW3BhZ2UgMjBdDQwNCklOVEVSTkVULURSQUZUICAgICAg IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIg MywgMTk5OA0KDQoNCg0KDQpbTFBEXSAgTGluZSBQcmludGVyIERhZW1vbiBQ cm90b2NvbCwgUkZDIDExNzksIElFVEYgaW5mb3JtYXRpb25hbA0KZG9jdW1l bnQuDQoNCltQSkxdICBQcmludGVyIEpvYiBMYW5ndWFnZSBUZWNobmljYWwg UmVmZXJlbmNlIE1hbnVhbCwgSGV3bGV0dC1QYWNrYXJkDQpwYXJ0IG51bWJl ciA1MDIxLTAzMjguDQoNCltQcnRNSUJdICBUaGUgUHJpbnRlciBNSUIsIFJG QyAxNzU5LCBJRVRGIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudC4NCg0KW1RJ UC9TSV0gIElFRUUgU3RhbmRhcmQgMTI4NC4xLCBUcmFuc3BvcnQgSW5kZXBl bmRlbnQgUHJpbnRlci9TeXN0ZW0NCkludGVyZmFjZS4NCg0KDQoNCjE1LjAg IEFVVEhPUlMNCg0KVGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCB3aXRoIHNp Z25pZmljYW50IGNvbnRyaWJ1dGlvbnMgZnJvbSB0aGUNCmZvbGxvd2luZyBp bmRpdmlkdWFscy4NCg0KICAgIFJvbiBCZXJnbWFuIChFZGl0b3IpDQogICAg RGF0YXByb2R1Y3RzIENvcnAuDQogICAgMTc1NyBUYXBvIENhbnlvbiBSb2Fk DQogICAgU2ltaSBWYWxsZXksIENBIDkzMDYzLTMzOTQNCg0KICAgIFBob25l OiA4MDUtNTc4LTQ0MjENCiAgICBGYXg6ICA4MDUtNTc4LTQwMDENCiAgICBF bWFpbDogcmJlcmdtYW5AZHBjLmNvbQ0KDQoNCiAgICBUb20gSGFzdGluZ3MN CiAgICBYZXJveCBDb3Jwb3JhdGlvbiwgRVNBRS0yMzENCiAgICA3MDEgUy4g QXZpYXRpb24gQmx2ZC4NCiAgICBFbCBTZWd1bmRvLCBDQSAgIDkwMjQ1DQoN CiAgICBQaG9uZTogMzEwLTMzMy02NDEzDQogICAgRmF4OiAgIDMxMC0zMzMt NTUxNA0KICAgIEVNYWlsOiBoYXN0aW5nc0BjcDEwLmVzLnhlcm94LmNvbQ0K DQoNCiAgICBTY290dCBBLiBJc2FhY3Nvbg0KICAgIE5vdmVsbCwgSW5jLg0K ICAgIDEyMiBFIDE3MDAgUw0KICAgIFByb3ZvLCBVVCAgIDg0NjA2DQoNCiAg ICBQaG9uZTogODAxLTg2MS03MzY2DQogICAgRmF4OiAgIDgwMS04NjEtNDAy NQ0KICAgIEVNYWlsOiBzY290dF9pc2FhY3NvbkBub3ZlbGwuY29tDQoNCg0K ICAgIEhhcnJ5IExld2lzDQogICAgSUJNIENvcnBvcmF0aW9uDQogICAgNjMw MCBEaWFnb25hbCBId3kNCiAgICBCb3VsZGVyLCBDTyA4MDMwMQ0KDQoNCg0K QmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAg ICAgICAgICAgICAgICAgICAgW3BhZ2UgMjFdDQwNCklOVEVSTkVULURSQUZU ICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAg ICBGZWIgMywgMTk5OA0KDQoNCg0KDQoNCiAgICBQaG9uZTogKDMwMykgOTI0 LTUzMzcNCiAgICBGYXg6ICAgKDMwMykgOTI0LTQ2NjINCiAgICBFbWFpbDog aGFycnlsQHVzLmlibS5jb20NCg0KDQogICAgQm9iIFBlbnRlY29zdA0KICAg IEhld2xldHQtUGFja2FyZCBDb3Jwb3JhdGlvbg0KICAgIDExMzExIENoaW5k ZW4gQm91bGV2YXJkDQogICAgQm9pc2UsIElEIDgzNzE0DQoNCiAgICBQaG9u ZTogKDIwOCkgMzk2LTMzMTINCiAgICBGYXg6ICAgKDIwOCkgMzk2LTQxMjIN CiAgICBFbWFpbDogYnBlbnRlY29AYm9pLmhwLmNvbQ0KDQoNCiAgICBTZW5k IGNvbW1lbnRzIHRvIHRoZSBwcmludG1pYiBXRyB1c2luZyB0aGUgSm9iIE1v bml0b3JpbmcgUHJvamVjdA0KICAgIChKTVApIE1haWxpbmcgTGlzdDogIGpt cEBwd2cub3JnDQoNCiAgICBGb3IgZnVydGhlciBpbmZvcm1hdGlvbiwgYWNj ZXNzIHRoZSBQV0cgd2ViIHBhZ2UgdW5kZXIgIkpNUCI6DQogICAgaHR0cDov L3d3dy5wd2cub3JnLw0KDQoNCk90aGVyIFBhcnRpY2lwYW50czoNCg0KICAg IENodWNrIEFkYW1zIC0gVGVrdHJvbml4DQogICAgS2VpdGggQ2FydGVyIC0g SUJNIENvcnBvcmF0aW9uDQogICAgQW5nZWxvIENhcnVzbyAtIFhlcm94DQog ICAgSmVmZiBDb3BlbGFuZCAtIFFNUw0KICAgIEFuZHkgRGF2aWRzb24gLSBU ZWt0cm9uaXgNCiAgICBNYWJyeSBEb3ppZXIgLSBRTVMNCiAgICBMZWUgRmVy cmVsIC0gQ2Fub24NCiAgICBEYXZpZCBLZWxsZXJtYW4gLSBOb3J0aGxha2Ug U29mdHdhcmUNCiAgICBSaWNrIExhbmRhdSAtIERpZ2l0YWwNCiAgICBKYXkg TWFydGluIC0gVW5kZXJzY29yZQ0KICAgIElyYSBNY0RvbmFsZCAtIFhlcm94 DQogICAgU3R1YXJ0IFJvd2xleSAtIEt5b2NlcmENCiAgICBCb2IgU2V0dGVy Ym8gLSBBZG9iZQ0KICAgIEdhaWwgU29uZ2VyIC0gRUZJDQogICAgTWlrZSBU aW1wZXJtYW4gLSBMZXhtYXJrDQogICAgV2lsbGlhbSBXYWduZXIgLSBEUEkv T3NpY29tDQogICAgQ2hyaXMgV2VsbGVucyAtIEludGVyd29ya2luZyBMYWJz DQogICAgUm9iIFdoaXR0bGUgLSBOb3ZlbGwNCiAgICBEb24gV3JpZ2h0IC0g TGV4bWFyaw0KICAgIExsb3lkIFlvdW5nIC0gTGV4bWFyaw0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAyMl0NDA0K From rbergma at dpc.com Thu Feb 5 11:27:08 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:14 2009 Subject: JMP> Update to the Job Submission Protocol Mapping Document Message-ID: <3.0.1.32.19980128001048.01045a80@garfield> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --3557085-27310-886696028=:55 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is the latest copy of the Job Submission Protocol Mapping document. This includes the corrections to the IPDS mapping section uncovered by Tom Hastings and Harry Lewis. I have also incorporated several minor editorial corrections which do not affect the content. I will not submit this new document to the IETF until next week to see if there are any more comments. Ron Bergman Dataproducts Corp. --3557085-27310-886696028=:55 Content-Type: APPLICATION/octet-stream; name="jmpmap09.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gQmVyZ21hbg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRGF0YXByb2R1Y3RzIENvcnAuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDUs IDE5OTgNCg0KDQogICAgICAgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9j b2wgTWFwcGluZyBSZWNvbW1lbmRhdGlvbnMNCiAgICAgICAgICAgICAgICAg ICAgICAgZm9yIHRoZSBKb2IgTW9uaXRvcmluZyBNSUINCg0KICAgICAgICAg ICAgICAgPGRyYWZ0LWlldGYtcHJpbnRtaWItam9iLXByb3RvbWFwLTAzLnR4 dD4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg NSwgMTk5OA0KDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICAgIFRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQuICBJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcNCiAgICAgZG9jdW1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFz LA0KICAgICBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90 aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICAgIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeA0KICAgICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyDQogICAgIGRvY3VtZW50 cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LURyYWZ0cw0KICAgICBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4NCiAgICAgcHJv Z3Jlc3MiLg0KDQogICAgIFRvIGxlYXJuIHRoZSBjdXJyZW50IHN0YXR1cyBv ZiBhbnkgSW50ZXJuZXQtRHJhZnQsIHBsZWFzZSBjaGVjayB0aGUNCiAgICAg IjFpZC1hYnN0cmFjdHMudHh0IiBsaXN0aW5nIGNvbnRhaW5lZCBpbiB0aGUg SW50ZXJuZXQtRHJhZnRzIFNoYWRvdw0KICAgICBEaXJlY3RvcmllcyBvbiBm dHAuaXMuY28uemEgKEFmcmljYSksIG5pYy5ub3JkdS5uZXQgKEV1cm9wZSks DQogICAgIG11bm5hcmkub3ouYXUgKFBhY2lmaWMgUmltKSwgZHMuaW50ZXJu aWMubmV0IChVUyBFYXN0IENvYXN0KSwgb3INCiAgICAgZnRwLmlzaS5lZHUg KFVTIFdlc3QgQ29hc3QpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEFic3RyYWN0DQoNCiAgICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBk ZWZpbmVzIHRoZSByZWNvbW1lbmRlZCBtYXBwaW5nIGZvciBtYW55DQogICAg IGN1cnJlbnRseSBwb3B1bGFyIEpvYiBzdWJtaXNzaW9uIHByb3RvY29scyB0 byBvYmplY3RzIGFuZA0KICAgICBhdHRyaWJ1dGVzIGluIHRoZSBKb2IgTW9u aXRvcmluZyBNSUIuDQoNCg0KDQoNCg0KDQpUQUJMRSBPRiBDT05URU5UUw0K DQoxLjAgIElOVFJPRFVDVElPTi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMNCjIuMCAgTElORSBQUklO VEVSIERBRU1PTiAoTFBSL0xQRCkgUFJPVE9DT0wuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNA0KMi4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQg dG8gTFBSL0xQRC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQoy LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIExQUi9MUEQuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCjIuMyAgT3RoZXIgTUlCIE9i amVjdHMgTWFwcGVkIHRvIExQUi9MUEQuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNQ0KMi40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0 byBMUEQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQoNCg0K DQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMV0NDA0KSU5URVJORVQtRFJB RlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAg ICAgIEZlYiA1LCAxOTk4DQoNCg0KDQoNCjMuMCAgQVBQTEVUQUxLIFBST1RP Q09MLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uNg0KMy4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gQXBw bGVUYWxrLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQozLjIgIE90 aGVyIEFwcGxlVGFsayBNYXBwaW5ncy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjYNCjQuMCAgSU5URVJORVQgUFJJTlRJTkcg UFJPVE9DT0wgKElQUCkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNg0KNC4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gSVBQLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQo0LjIgIGptSm9i SW5kZXggTWFwcGVkIHRvIElQUC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjcNCjQuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFw cGVkIHRvIElQUC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Nw0KNC40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBJUFAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQo1LjAgIElOVEVMTElH RU5UIFBSSU5URVIgREFUQSBTVFJFQU0gKElQRFMpLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjkNCjUuMSBqbUpvYlN1Ym1pc3Npb25JZCBNYXBwZWQg dG8gSVBEUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOQ0K NS4yICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBJUERTLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQo2LjAgIERPQ1VNRU5UIFBS SU5USU5HIEFQUExJQ0FUSU9OIChEUEEpLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTANCjYuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRv IERQQS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KNi4y ICBqbUpvYkluZGV4IE1hcHBlZCB0byBEUEEuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQo2LjMgIE90aGVyIE1JQiBPYmpl Y3RzIE1hcHBlZCB0byBEUEEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTENCjYuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8g RFBBLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KNy4wICBO T1ZFTEwgRElTVFJJQlVURUQgUFJJTlQgU0VSVklDRSAoTkRQUykuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjEzDQo3LjEgIGptSm9iU3VibWlzc2lvbklE IE1hcHBlZCB0byBORFBTLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTMNCjcuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gTkRQUy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KNy4zICBPdGhl ciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gTkRQUy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjEzDQo3LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAg TWFwcGVkIHRvIE5EUFMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTQNCjguMCAgUFJJTlRFUiBKT0IgTEFOR1VBR0UgKFBKTCkuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNQ0KOC4xICBqbUpvYlN1 Ym1pc3Npb25JRCBNYXBwZWQgdG8gUEpMLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjE1DQo4LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFBK TC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYN CjguMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRvIFBKTC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNg0KOC40ICBUaGUgQXR0cmli dXRlIEdyb3VwIE1hcHBlZCB0byBQSkwuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjE2DQo5LjAgIFBPU1RTQ1JJUFQuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYNCjku MSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFBvc3RTY3JpcHQuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNg0KOS4yICBPdGhlciBNSUIgT2Jq ZWN0cyBhbmQgQXR0cmlidXRlcyBNYXBwZWQgdG8gUG9zdFNjcmlwdC4uLi4u Li4uLi4uLjE3DQoxMC4wICBORVRXQVJFIFBTRVJWRVIuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcNCjEwLjEg IGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBQU2VydmVyLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNw0KMTAuMiAgam1Kb2JJbmRleCBNYXBw ZWQgdG8gUFNlcnZlci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjE3DQoxMC4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gUEpM Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcNCjEwLjQgIFRo ZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIFBTZXJ2ZXIuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xOA0KMTEuMCAgTkVUV0FSRSBOUFJJTlRFUiBv ciBSUFJJTlRFUi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjE4DQoxMi4wICBTRVJWRVIgTUVTU0FHRSBCTE9DSyAoU01CKSBQUk9UT0NP TC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTgNCjEyLjEgIGptSm9i U3VibWlzc2lvbklEIE1hcHBlZCB0byBTTUIuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xOQ0KMTIuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8g U01CLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5 DQoxMi4zICBPdGhlciBNSUIgb2JqZWN0cyBNYXBwZWQgdG8gU01CLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkNCjEzLjAgIFRSQU5TUE9S VCBJTkRFUEVOREVOVCBQUklOVEVSL1NZU1RFTSBJTlRFUkZBQ0UgKFRJUC9T SSkuLi4uLi4uLi4xOQ0KMTMuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVk IHRvIFRJUC9TSS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5DQox My4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBUSVAvU0kuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjANCjEzLjMgIE90aGVyIE1JQiBP YmplY3RzIE1hcHBlZCB0byBUSVAvU0kuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4yMA0KMTMuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQg dG8gVElQL1NJLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwDQoxNC4w ICBSRUZFUkVOQ0VTLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMjANCjE1LjAgIEFVVEhPUlMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4yMQ0KDQoNCg0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAg ICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAg W3BhZ2UgMl0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Np b24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiA1LCAxOTk4DQoNCg0K DQoNCjEuMCAgSU5UUk9EVUNUSU9ODQoNClRoZSBKb2IgTW9uaXRvcmluZyBN SUIgW0pvYk1JQl0gaXMgaW50ZW5kZWQgdG8gYmUgaW1wbGVtZW50ZWQgaW4g YQ0KZGV2aWNlIG9yIHNlcnZlciB0aGF0IHN1cHBvcnRzIGFueSBqb2Igc3Vi bWlzc2lvbiBwcm90b2NvbC4gIEhvd2V2ZXIsDQp0aGUgaW5mb3JtYXRpb24g YXZhaWxhYmxlIGFuZCB0aGUgbWV0aG9kIG9mIHByZXNlbnRhdGlvbiB2YXJp ZXMNCnNpZ25pZmljYW50bHkgYnkgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2wu ICBBIGNvbW1vbiBtZXRob2Qgb2YgbWFwcGluZw0Kam9iIHN1Ym1pc3Npb24g aW5mb3JtYXRpb24gdG8gdGhlIEpvYiBNb25pdG9yaW5nIE1JQiBpcyBlc3Nl bnRpYWwgZm9yDQppbnRlcm9wZXJhYmlsaXR5IG9mIEpvYiBNSUIgYWdlbnRz IGFuZCBtb25pdG9yaW5nIGFwcGxpY2F0aW9ucy4gIFRoaXMNCmRvY3VtZW50 IGRlZmluZXMgcmVjb21tZW5kZWQgbWFwcGluZ3MgZm9yIG1vc3QgcG9wdWxh ciBqb2Igc3VibWlzc2lvbg0KcHJvdG9jb2xzIHRvIGluc3VyZSB0aGlzIGNv bXBhdGliaWxpdHkuDQoNCkFsbCBtYXBwaW5ncyBhcmUgdW5pZGlyZWN0aW9u YWwgZnJvbSB0aGUgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2wgdG8gdGhlDQpN SUIuICBJdCBpcyBhc3N1bWVkIHRoYXQgc3VwcG9ydCBvZiB0aGUgam9iIHN1 Ym1pc3Npb24gcHJvdG9jb2wgaW4gdGhlDQpwcmludGVyIGltcGxpZXMgdGhh dCB0aGUgcmV2ZXJzZSBpbmZvcm1hdGlvbiBmbG93IGlzIHByZXNlbnRseSBk ZWZpbmVkDQphbmQgZG9lcyBub3QgcmVxdWlyZSBpbnRlcmFjdGlvbiBmcm9t IHRoZSBNSUIuICBUaGlzIG1hcHBpbmcgaXMgbm90DQpkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQgYXMgaXQgc2hvdWxkIGJlIG9idmlvdXMuDQoNClRoaXMg ZG9jdW1lbnQgcmVmZXJzIHRvIHN5c3RlbSBjb25maWd1cmF0aW9ucyB0aGF0 IGFyZSBkZWZpbmVkIGluIHRoZQ0KSm9iIE1vbml0b3JpbmcgTUlCIFtKb2JN SUJdLiAgRm9yIHRob3NlIHJlYWRlcnMgdGhhdCBhcmUgZmFtaWxpYXIgd2l0 aA0KdGhlIGNvbmZpZ3VyYXRpb24gZGVzY3JpcHRpb25zLCBhIHNob3J0IHN1 bW1hcnkgYXBwZWFycyBoZXJlLiAgUGxlYXNlDQpzZWUgdGhlIEpvYiBNSUIg ZG9jdW1lbnQgZm9yIGZ1cnRoZXIgZGV0YWlscy4NCg0KICAgQ29uZmlndXJh dGlvbiAxOiAgVGhpcyBpcyBhIHNpbXBsZSBwZWVyLXRvLXBlZXIgc3lzdGVt IHdoaWNoIGNvbnRhaW5zDQogICAgICAgb25seSBhIGNsaWVudCBhbmQgYSBw cmludGVyLiAgVGhlIEpvYiBNSUIgYWdlbnQgaXMgcmVzaWRlbnQgaW4NCiAg ICAgICB0aGUgcHJpbnRlci4NCg0KICAgQ29uZmlndXJhdGlvbiAyOiAgVGhp cyBzeXN0ZW0gY29udGFpbnMgYSBjbGllbnQsIHNlcnZlciwgYW5kIGENCiAg ICAgICBwcmludGVyLiAgVGhlIEppYiBNSUIgYWdlbnQgaXMgcmVzaWRlbnQg aW4gdGhlIHNlcnZlci4NCg0KICAgQ29uZmlndXJhdGlvbiAzOiAgVGhpcyBz eXN0ZW0sIGFzIGluIGNvbmZpZ3VyYXRpb24gMiwgY29udGFpbnMgYQ0KICAg ICAgIGNsaWVudCwgc2VydmVyLCBhbmQgYSBwcmludGVyLiAgSW4gdGhpcyBj YXNlIHRoZSBKb2IgTUlCIGFnZW50IGlzDQogICAgICAgaW1wbGVtZW50ZWQg d2l0aGluIHRoZSBwcmludGVyLg0KDQpUaGUgbW9zdCBpbXBvcnRhbnQgb2Jq ZWN0IHRvIGJlIG1hcHBlZCBpcyBqbUpvYlN1Ym1pc3Npb25JRCwgc2luY2Ug dGhpcw0KaXMgYSBtZXRob2QgZm9yIHRoZSB1c2VyIG9yIGNsaWVudCB0byBk ZXRlcm1pbmUgdGhlIGptSm9iSW5kZXggZm9yIGENCnN1Ym1pdHRlZCBqb2Iu ICBUaGVyZWZvcmUsIGptSm9iU3VibWlzc2lvbklEIGlzIHNwZWNpZmllZCBm b3IgYWxsIGpvYg0Kc3VibWlzc2lvbiBwcm90b2NvbHMgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50LiAgVGhlIHJlbWFpbmluZyBvYmplY3RzDQptYXBwZWQg aW5jbHVkZSBvbmx5IHRob3NlIGl0ZW1zIHRoYXQgaGF2ZSB0aGUgZXF1aXZh bGVudCBpbmZvcm1hdGlvbg0KcHJlc2VudGVkIHRvIHRoZSBwcmludGVyIGJ5 IHRoZSBqb2Igc3VibWlzc2lvbiBwcm90b2NvbC4NCg0KV2hpbGUgdGhpcyBk b2N1bWVudCBwbGFjZXMgYSBzdHJvbmcgZW1waGFzaXMgb24gam1Kb2JTdWJt aXNzaW9uSUQNCm1hcHBpbmcgdG8gb2J0YWluIGptSm9iSW5kZXgsIHRoZSBw cmVmZXJyZWQgbWV0aG9kIGlzIHRocm91Z2ggdGhlIHVzZSBvZg0KYSBiaS1k aXJlY3Rpb25hbCBwcm90b2NvbCB0aGF0IHJldHVybnMgdGhlIHZhbHVlIG9m IGptSm9iSW5kZXggdG8gdGhlDQpjbGllbnQsIHN1Y2ggYXMgSVBQLiAgV2hl biBhIGJpLWRpcmVjdGlvbmFsIHByb3RvY29sIHRoYXQgcmV0dXJucw0Kam1K b2JJbmRleCBpcyBpbiB1c2UsIHRoZSBqbUpvYlN1Ym1pc3Npb25JRCBvYmpl Y3QgaGFzIG5vIHZhbHVlIHRvIHRoZQ0KY2xpZW50LiAgV2hlbiB0aGUgam1K b2JJbmRleCBjYW5ub3QgYmUgcmV0dXJuZWQsIHRoZSB1c2Ugb2YgYSBjbGll bnQNCmRlZmluZWQgam1Kb2JTdWJtaXNzaW9uSUQgaXMgcHJlZmVycmVkIG92 ZXIgYW4gYWdlbnQgZGVyaXZlZCB2YWx1ZS4gIFRoZQ0KY2xpZW50IGRlZmlu ZWQgdmVyc2lvbiBhbGxvd3MgZm9yIHJldHJpZXZhbCBvZiBqbUpvYkluZGV4 IHVzaW5nIGEgc2luZ2xlDQpTTk1QIEdldCBvcGVyYXRpb24sIHNpbmNlIGpt Sm9iU3VibWlzc2lvbklEIGlzIHRoZSBpbmRleCBpbnRvIHRoZQ0Kam1Kb2JJ RFRhYmxlLiAgQW4gYWdlbnQgZGVyaXZlZCB2YWx1ZSB3aWxsIHJlcXVpcmUg YSBzZWFyY2ggdGhyb3VnaA0KbXVsdGlwbGUgZW50cmllcyBpbiB0aGUgam1K b2JJRFRhYmxlLg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAg ICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAz XQ0MDQpJTlRFUk5FVC1EUkFGVCAgICAgICBKb2IgU3VibWlzc2lvbiBQcm90 b2NvbCBNYXBwaW5nICAgICAgICAgRmViIDUsIDE5OTgNCg0KDQoNCg0KVGhl IG1ham9yaXR5IG9mIHRoZSBwcm90b2NvbHMgbWFwcGVkIGluIHRoaXMgZG9j dW1lbnQgYXJlIG9yaWVudGVkDQp0b3dhcmRzIG5ldHdvcmsgam9iIHN1Ym1p c3Npb24uICBIb3dldmVyLCB0aGUgSm9iIE1vbml0b3JpbmcgTUlCIGlzIGFs c28NCmludGVuZGVkIHRvIG1vbml0b3IgcHJpbnQgam9icyByZWNlaXZlZCBm cm9tIG90aGVyIHRoYW4gbmV0d29yayBwb3J0cywNCnN1Y2ggYXMgcGFyYWxs ZWwgYW5kIHNlcmlhbCBwb3J0cy4gIFNvbWUgb2YgdGhlIGpvYiBzdWJtaXNz aW9uIHByb3RvY29scw0KaW5jbHVkZWQgdGhhdCBhcmUgdXNlZCB3aXRoIG5v bi1uZXR3b3JrZWQgcG9ydHMgYXJlIFBKTCwgUG9zdFNjcmlwdCwgYW5kDQpU SVAvU0kuICBJbiBhZGRpdGlvbiwgdGhlIEpvYiBNb25pdG9yaW5nIE1JQiBj YW4gYmUgdXNlZCB3aXRoIHByaW50IGpvYnMNCnRoYXQgYXJlIGludGVybmFs bHkgZ2VuZXJhdGVkLCBzdWNoIGFzIHNlbGYgdGVzdCBwYWdlcy4gIEluIHRo aXMgbGF0dGVyDQpjYXNlLCBubyBtYXBwaW5nIGlzIHJlcXVpcmVkIHNpbmNl IGFsbCBqb2Igc3VibWlzc2lvbiBwcm90b2NvbHMgYXJlDQpieXBhc3NlZC4N Cg0KDQoNCjIuMCAgTElORSBQUklOVEVSIERBRU1PTiAoTFBSL0xQRCkgUFJP VE9DT0wNCg0KVGhlIExQUi9MUEQgcHJpbnRpbmcgcHJvdG9jb2wgW0xQRF0g aXMgdXNlZCB3aXRoIEJTRCBVTklYIHN5c3RlbXMgaW4gdGhlDQpjbGllbnQt c2VydmVyLXByaW50ZXIgY29uZmlndXJhdGlvbi4gIFVzYWdlIG9mIHRoZSBK b2IgTW9uaXRvcmluZyBNSUINCndpdGggTFBSL0xQRCB3aWxsIG1vc3QgbGlr ZWx5IGNvbmZvcm0gdG8gQ29uZmlndXJhdGlvbiAzLCB3aGVyZSB0aGUNCm1v bml0b3IgYXBwbGljYXRpb24gb3IgdGhlIHNlcnZlciB1c2VzIFNOTVAgdG8g b2J0YWluIGpvYiBpbmZvcm1hdGlvbg0KZnJvbSB0aGUgcHJpbnRlci4gIFRo ZSBjbGllbnQgY29tbXVuaWNhdGVzIHdpdGggdGhlIFVOSVggc2VydmVyIHVz aW5nDQp0aGUgZXhpc3RpbmcgTFBEIHByb3RvY29sIHRvIG9idGFpbiBqb2Ig aW5mb3JtYXRpb24uDQoNClRoZSBMUFIvTFBEIHByb3RvY29sIGlzIGFsc28g dXNlZCBpbiB0aGUgV2luZG93cyBlbnZpcm9ubWVudCB0bw0KaW1wbGVtZW50 IHBlZXItdG8tcGVlciBwcmludGluZywgYXMgc2hvd24gaW4gY29uZmlndXJh dGlvbiAxLiAgSW4gdGhpcw0KY2FzZSwgU05NUCBpcyB1c2VkIGJ5IHRoZSBj bGllbnQgYW5kL29yIHRoZSBtb25pdG9yIGFwcGxpY2F0aW9uIHRvDQpvYnRh aW4gdGhlIGpvYiBpbmZvcm1hdGlvbi4NCg0KT25lIG9mIHRoZSBtYWpvciBw cm9ibGVtcyBvZiBMUFIvTFBEIGlzIHRoZSBsYXJnZSBudW1iZXIgb2YgdmVu ZG9yDQp1bmlxdWUgZXh0ZW5zaW9ucyBjdXJyZW50bHkgdXNlZCB3aXRoIHRo ZSBwcm90b2NvbCBhbmQgdGhlIHJlc3VsdGluZw0KY29tcGF0aWJpbGl0eSBp c3N1ZXMgYmV0d2VlbiBhdmFpbGFibGUgaW1wbGVtZW50YXRpb25zLiAgVG8g YXZvaWQgdGhlc2UNCmlzc3VlcywgdGhpcyBtYXBwaW5nIG9mIExQUi9MUEQg aXMgcmVzdHJpY3RlZCB0byB0aGUgcHJvdG9jb2wgYXMgZGVmaW5lZA0KYnkg UkZDIDExNzkuDQoNClRoZSBMUFIvTFBEIHByb3RvY29sIHRyYW5zZmVycyBw cmludCBqb2IgZGF0YSBhbmQgY29udHJvbCBpbmZvcm1hdGlvbiBpbg0Kc2Vw YXJhdGUgZmlsZXMsIGtub3duIGFzIHRoZSBEYXRhIEZpbGUgYW5kIENvbnRy b2wgRmlsZSwgcmVzcGVjdGl2ZWx5Lg0KTW9zdCBvZiB0aGUgaW5mb3JtYXRp b24gY29uY2VybmluZyB0aGUgcHJpbnQgam9iIGlzIGNvbnRhaW5lZCBpbiB0 aGUNCkNvbnRyb2wgRmlsZS4gIEluIG1hbnkgTFBEIGltcGxlbWVudGF0aW9u cywgdGhlIENvbnRyb2wgRmlsZSBpcw0KdHJhbnNmZXJyZWQgZm9sbG93aW5n IHRoZSBEYXRhIEZpbGUuICBUaHVzIG11Y2ggb2YgdGhlIGluZm9ybWF0aW9u DQpjb25jZXJuaW5nIHRoZSBqb2IgbWF5IG5vdCBiZSBhdmFpbGFibGUgdW50 aWwgdGhlIGNvbXBsZXRpb24gb2YgdGhlIGRhdGENCnRyYW5zbWlzc2lvbi4N Cg0KDQoyLjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBMUFIvTFBE DQoNClRoZSBMUFIvTFBEIFJlY2VpdmUgRGF0YSBGaWxlIGNvbW1hbmQgY29u dGFpbnMgYSBwYXJhbWV0ZXIgd2hpY2ggZGVmaW5lcw0KdGhlIG5hbWUgb2Yg dGhlIGRhdGEgZmlsZS4gIFRoaXMgbmFtZSBmaWVsZCBpcyBzdHJ1Y3R1cmVk IGFzIGZvbGxvd3M6DQoNCiAgICAgICAgZGZhWFhYPGhvc3QtbmFtZT4gIG9y ICBkYVhYWFg8aG9zdC1uYW1lPg0KDQpXaGVyZSBYWFggb3IgWFhYWCBpcyB0 aGUgbnVtZXJpYyBqb2IgbnVtYmVyIGFzc2lnbmVkIGJ5IHRoZSBMUFIvTFBE DQpjbGllbnQgc3VibWl0dGluZyB0aGUgcHJpbnQgam9iLiAgVGhlIHJlY29t bWVuZGVkIG1hcHBpbmcgb2YgdGhpcyBuYW1lDQpmaWVsZCB0byBqbUpvYlN1 Ym1pc3Npb25JRCBpczoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAg ICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3Bh Z2UgNF0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24g UHJvdG9jb2wgTWFwcGluZyAgICAgICAgIEZlYiA1LCAxOTk4DQoNCg0KDQoN CiAgb2N0ZXQgMTogICAnOScNCg0KICBvY3RldHMgMi00MDogIENvbnRhaW5z IHRoZSA8aG9zdC1uYW1lPiBwb3J0aW9uIG9mIHRoZSBuYW1lIGZpZWxkLiAg SWYNCiAgICAgICAgICAgICAgICB0aGUgPGhvc3QtbmFtZT4gcG9ydGlvbiBp cyBsZXNzIHRoYW4gNDAgb2N0ZXRzLCB0aGUNCiAgICAgICAgICAgICAgICBs ZWZ0LW1vc3QgY2hhcmFjdGVyIGluIHRoZSBzdHJpbmcgc2hhbGwgYXBwZWFy IGluIG9jdGV0DQogICAgICAgICAgICAgICAgcG9zaXRpb24gMi4gIEFueSB1 bnVzZWQgcG9ydGlvbiBvZiB0aGlzIGZpZWxkIHNoYWxsIGJlDQogICAgICAg ICAgICAgICAgZmlsbGVkIHdpdGggc3BhY2VzLiAgT3RoZXJ3aXNlLCBvbmx5 IHRoZSBsYXN0IDM5IGJ5dGVzDQogICAgICAgICAgICAgICAgc2hhbGwgYmUg aW5jbHVkZWQuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgJzAwMDAwWFhYJyBvciAn MDAwMFhYWFgnLCB3aGVyZSBYWFggb3IgWFhYWCBpcyB0aGUNCiAgICAgICAg ICAgICAgICAgZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9u IG9mIHRoZSBMUFIvTFBEDQogICAgICAgICAgICAgICAgIGpvYiBudW1iZXIu DQoNCg0KMi4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBMUFIvTFBEDQoNClRo ZSBqb2IgaW5kZXggKGptSm9iSW5kZXgpIGlzIGFzc2lnbmVkIGJ5IHRoZSBT Tk1QIGpvYiBtb25pdG9yaW5nIGFnZW50DQphbmQgaXMgaW5kZXBlbmRlbnQg b2YgdGhlIFhYWCAob3IgWFhYWCkgaW5kZXggYXNzaWduZWQgYnkgdGhlIExQ Ui9MUEQNCmNsaWVudC4gIFRoaXMgd2lsbCBhbGxvdyB0aGUgU05NUCBhZ2Vu dCB0byB0cmFjayBqb2JzIHJlY2VpdmVkIGZyb20NCm11bHRpcGxlIHNvdXJj ZXMuDQoNCg0KMi4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gTFBS L0xQRA0KDQpNSUIgT2JqZWN0ICAgICAgICAgICAgICAgICAgICB8IExQUi9M UEQgUGFyYW1ldGVyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kam1K b2JLT2N0ZXRzUGVyQ29weVJlcXVlc3RlZCAgfCBOdW1iZXIgb2YgYnl0ZXMg YXMgZGVmaW5lZCBpbiB0aGUgRGF0YQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgRmlsZQ0Kam1Kb2JPd25lciAgICAgICAgICAgICAgICAg ICAgfCBDb250cm9sIGZpbGUgY29tbWFuZCBjb2RlID0gUCAoVXNlciBJZCkN Cg0KDQoyLjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIExQRA0K DQpPdGhlciBhdHRyaWJ1dGVzIHRoYXQgYXJlIGFwcGxpY2FibGUsIGJ1dCBu b3QgZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24NCnN1Y2ggYXMgYXR0cmlidXRl cyB0aGF0IG1hcCB0byBhIHZlbmRvciB1bmlxdWUgZXh0ZW5zaW9uLCBtYXkg YWxzbyBiZQ0KaW5jbHVkZWQuDQoNCk1JQiBhdHRyaWJ1dGUgICAgICAgICB8 IExQUi9MUEQgaW5mb3JtYXRpb24gICAgICAgICAgICAgfCBEYXRhIHR5cGUN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tDQpqb2JOYW1lICAgICAgICAg ICAgICAgfCBOYW1lIG9mIHRoZSBkYXRhIGZpbGUgKG5vdGUgMSkgIHwgT2N0 ZXQgU3RyaW5nDQpxdWV1ZU5hbWVSZXF1ZXN0ZWQgICAgfCBRdWV1ZSBuYW1l IGZyb20gdGhlIERhdGEgRmlsZSAgIHwgT2N0ZXQgU3RyaW5nDQpmaWxlTmFt ZSAgICAgICAgICAgICAgfCBTb3VyY2UgRmlsZSBOYW1lIChub3RlcyAyLCAz KSAgIHwgT2N0ZXQgU3RyaW5nDQpkb2N1bWVudE5hbWUgICAgICAgICAgfCBE b2N1bWVudCB0aXRsZSAobm90ZXMgMiwgNCkgICAgIHwgT2N0ZXQgU3RyaW5n DQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4gU2VlIHNlY3Rpb24gMi4xIChq bUpvYlN1Ym1pc3Npb25JRCkuDQogIDIuIFRoZSBpbmZvcm1hdGlvbiBpcyBv cHRpb25hbCBpbiB0aGUgQ29udHJvbCBGaWxlLiAgVGhlIGF0dHJpYnV0ZQ0K ICAgICBzaG91bGQgYmUgaW5jbHVkZWQgaWYgcHJlc2VudCBpbiB0aGUgQ29u dHJvbCBGaWxlLg0KICAzLiBDb250cm9sIGZpbGUgY29tbWFuZCBjb2RlID0g Ti4NCiAgNC4gQ29udHJvbCBmaWxlIGNvbW1hbmQgY29kZSA9IEouDQoNCg0K DQoNCkJlcmdtYW4gICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFs ICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDVdDQwNCklOVEVSTkVULURS QUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAg ICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQoNCg0KMy4wICBBUFBMRVRBTEsg UFJPVE9DT0wNCg0KQXBwbGVUYWxrIHdhcyBvcmlnaW5hbGx5IGRldmVsb3Bl ZCBhcyBhIHBlZXItdG8tcGVlciBuZXR3b3JrIHByb3RvY29sLA0KYXMgZGVz Y3JpYmVkIGluIGNvbmZpZ3VyYXRpb24gMSwgZm9yIHVzZSB3aXRoIEFwcGxl IE1hY2ludG9zaCBjb21wdXRlcnMuDQpUb2RheSwgcHJpbnQgc3Bvb2xlcnMg YXJlIGFsc28gYXZhaWxhYmxlIGZvciB1c2Ugd2l0aCBNYWNpbnRvc2ggY29t cHV0ZXINCm5ldHdvcmtzIHRoYXQgY29uZm9ybSB0byBjb25maWd1cmF0aW9u cyAyLzMuICBJbiBhZGRpdGlvbiwgcHJpbnRpbmcgd2l0aA0KdGhlIEFwcGxl VGFsayBwcm90b2NvbCBpcyBzdXBwb3J0ZWQgZnJvbSBib3RoIFdpbmRvd3Mg TlQgc2VydmVycyBhbmQNCk5vdmVsbCBzZXJ2ZXJzIGFsc28gcGVyIGNvbmZp Z3VyYXRpb25zIDIvMy4NCg0KVGhlIEFwcGxlVGFsayBwcm90b2NvbCBwcm92 aWRlcyB2ZXJ5IGxpdHRsZSBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSB1c2Vk DQp3aXRoIHRoZSBKb2IgTW9uaXRvcmluZyBNSUIuICBUaGUgTWFjaW50b3No IHByaW50IGRyaXZlcnMgYXJlIGFibGUgdG8NCnByb3ZpZGUgaW5mb3JtYXRp b24gY29uY2VybmluZyB0aGUgdXNlciBhbmQgZG9jdW1lbnQgbmFtZSBidXQg aW1iZWQgdGhpcw0KaW5mb3JtYXRpb24gaW4gdGhlIFBETCwgd2hpY2ggaXMg dHlwaWNhbGx5IFBvc3RTY3JpcHQuICBUaGUgcHJlZmVycmVkDQpqbUpvYlN1 Ym1pc3Npb25JRCBpcyBjb25zdHJ1Y3RlZCBmcm9tIHRoZSBpbmZvcm1hdGlv biBpbiB0aGUgUG9zdFNjcmlwdA0KZmlsZSwgYXMgZGVmaW5lZCBpbiBzZWN0 aW9uIDkuMC4NCg0KDQozLjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0 byBBcHBsZVRhbGsNCg0KQW4gYWx0ZXJuYXRpdmUgam1Kb2JTdWJtaXNzaW9u SUQgbWF5IGJlIGNvbnN0cnVjdGVkIGZyb20gdGhlIENvbm5lY3Rpb24NCklk ZW50aWZpZXIgY29udGFpbmVkIGluIHRoZSBBcHBsZVRhbGsgUHJpbnRlciBB Y2Nlc3MgUHJvdG9jb2wgKFBBUCkNCmhlYWRlci4gIFNpbmNlIHRoZSBDb25u ZWN0aW9uIElkIGlzIG5vdCByZWFkaWx5IGF2YWlsYWJsZSBpbiBhbnkgb2Yg dGhlDQpkZWZpbmVkIEFwcGxlVGFsayBpbXBsZW1lbnRhdGlvbnMsIHRoaXMg YXBwcm9hY2ggbWF5IGJlIG9mIGxpdHRsZQ0KdXRpbGl0eS4NCg0KICBvY3Rl dCAxOiAgICdBJw0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIEFw cGxlVGFsayBwcmludGVyIG5hbWUsIHdpdGggdGhlIGZpcnN0DQogICAgICAg ICAgICAgICAgY2hhcmFjdGVyIG9mIHRoZSBuYW1lIGluIG9jdGV0IDIuICBB cHBsZVRhbGsgcHJpbnRlcg0KICAgICAgICAgICAgICAgIG5hbWVzIGFyZSBh IG1heGltdW0gb2YgMzEgY2hhcmFjdGVycy4gIEFueSB1bnVzZWQNCiAgICAg ICAgICAgICAgICBwb3J0aW9uIG9mIHRoaXMgZmllbGQgc2hhbGwgYmUgZmls bGVkIHdpdGggc3BhY2VzLg0KDQogIG9jdGV0cyA0MS00ODogICcwMDAwMFhY WCcsIHdoZXJlICdYWFgnIGlzIHRoZSBkZWNpbWFsIChBU0NJSSBjb2RlZCkN CiAgICAgICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgdGhlIENvbm5l Y3Rpb24gSWQuDQoNCg0KMy4yICBPdGhlciBBcHBsZVRhbGsgTWFwcGluZ3MN Cg0KTm8gb3RoZXIgSm9iIE1JQiBvYmplY3RzIG9yIHBhcmFtZXRlcnMgY2Fu IGJlIGRlcml2ZWQgZnJvbSBpbmZvcm1hdGlvbg0KYXZhaWxhYmxlIGluIHRo ZSBBcHBsZVRhbGsgaGVhZGVycw0KDQoNCg0KNC4wICBJTlRFUk5FVCBQUklO VElORyBQUk9UT0NPTCAoSVBQKQ0KDQpUaGUgSW50ZXJuZXQgUHJpbnRpbmcg UHJvdG9jb2wgW0lQUF0gc3VwcG9ydHMgcHJpbnRpbmcgdXNpbmcgYW55IG9u ZSBvZg0KdGhlIHRocmVlIHBvc3NpYmxlIGNvbmZpZ3VyYXRpb25zLiAgRm9y IGNvbmZpZ3VyYXRpb24gMiwgdGhlIG1hcHBpbmcNCmRlZmluZWQgaGVyZWlu IGlzIHBlcmZvcm1lZCBvbiBhbiBhZ2VudCB3aXRoaW4gdGhlIHNlcnZlci4g IE90aGVyd2lzZSwNCnRoZSBtYXBwaW5nIGlzIHBlcmZvcm1lZCBvbiBhbiBh Z2VudCB3aXRoaW4gdGhlIHByaW50ZXIuDQoNCg0KDQoNCkJlcmdtYW4gICAg ICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAg ICAgICAgIFtwYWdlIDZdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBT dWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5 OA0KDQoNCg0KDQoNCjQuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRv IElQUA0KDQpJUFAgY29udGFpbnMgYSByaWNoIHNldCBvZiBwYXJhbWV0ZXJz IHdoaWNoIGFsbG93IHNldmVyYWwgbWV0aG9kcyBvZg0KY3JlYXRpbmcgdGhl IGptSm9iU3VibWlzc2lvbklEIG9iamVjdC4gIFRvIHByZXZlbnQgaW50ZXJv cGVyYWJpbGl0eQ0KcHJvYmxlbXMsIHRoZSBwcmVmZXJyZWQgbWV0aG9kIGlz IHRvIHVzZSB0aGUgSVBQIGpvYi11cmkgYXR0cmlidXRlIGFzDQpmb2xsb3dz Og0KDQogIG9jdGV0IDE6ICAgJzQnDQoNCiAgb2N0ZXRzIDItNDA6ICBDb250 YWlucyB0aGUgSVBQIGpvYi11cmkgam9iIGRlc2NyaXB0aW9uIGF0dHJpYnV0 ZQ0KICAgICAgICAgICAgICAgIGdlbmVyYXRlZCBieSB0aGUgcHJpbnRlci4g IChUaGUgam9iLXVyaSBpcyByZXR1cm5lZCB0bw0KICAgICAgICAgICAgICAg IHRoZSBjbGllbnQgYnkgSVBQLikgIElmIHRoZSBqb2ItdXJpIGlzIGxlc3Mg dGhhbiA0MA0KICAgICAgICAgICAgICAgIG9jdGV0cywgdGhlIGxlZnQtbW9z dCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmluZyBzaGFsbA0KICAgICAgICAgICAg ICAgIGFwcGVhciBpbiBvY3RldCBwb3NpdGlvbiAyLiAgQW55IHVudXNlZCBw b3J0aW9uIG9mIHRoaXMNCiAgICAgICAgICAgICAgICBmaWVsZCBzaGFsbCBi ZSBmaWxsZWQgd2l0aCBzcGFjZXMuICBPdGhlcndpc2UsIG9ubHkgdGhlDQog ICAgICAgICAgICAgICAgbGFzdCAzOSBieXRlcyBzaGFsbCBiZSBpbmNsdWRl ZC4NCg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlucyB0aGUgZGVjaW1hbCAo QVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9uIG9mDQogICAgICAgICAgICAg ICAgIHRoZSBqb2ItaWQgam9iIGRlc2NyaXB0aW9uIGF0dHJpYnV0ZS4gIExl YWRpbmcgemVyb3MNCiAgICAgICAgICAgICAgICAgc2hhbGwgYmUgaW5zZXJ0 ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0ZXQgZmllbGQuDQoNCg0KNC4y ICBqbUpvYkluZGV4IE1hcHBlZCB0byBJUFANCg0KVGhlIGpvYiBpbmRleCAo am1Kb2JJbmRleCkgYXNzaWduZWQgYnkgdGhlIFNOTVAgam9iIG1vbml0b3Jp bmcgYWdlbnQgaXMNCnJldHVybmVkIHRvIHRoZSBjbGllbnQgYnkgSVBQIGFz IHRoZSBqb2ItaWQgam9iIGRlc2NyaXB0aW9uIGF0dHJpYnV0ZS4NCihTaW5j ZSBJUFAgZG9lcyBub3QgcmVxdWlyZSBjb25zZWN1dGl2ZWx5IGdlbmVyYXRl ZCBqb2ItaWRzLCB0aGUgYWdlbnQNCm1heSByZWNlaXZlIGpvYnMgZnJvbSBt dWx0aXBsZSBjbGllbnRzIGFuZCBjYW4gYXNzaWduIGptSm9iSW5kZXggaW4g YW4NCmFzY2VuZGluZyBzZXF1ZW5jZSBpbmRlcGVuZGVudCBvZiB0aGUgc3Vi bWl0dGluZyBqb2IgY2xpZW50LikgIFRoZSBJUFANCmpvYi1pZCBtdXN0IGJl IHJlc3RyaWN0ZWQgdG8gdGhlIHJhbmdlIG9mIDEgdG8gOTksOTk5LDk5OSAo ZGVjaW1hbCkgdG8NCmFsbG93IHRoZSB2YWx1ZSB0byBiZSBwcm9wZXJseSBy ZXByZXNlbnRlZCBpbiBqbUpvYlN1Ym1pc3Npb25JRC4NCg0KDQo0LjMgIE90 aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0byBJUFANCg0KTUlCIE9iamVjdCAg ICAgICAgICAgICAgICAgICAgICAgfCBJUFAgSm9iIGF0dHJpYnV0ZQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpqbUpvYlN0YXRlICAgICAgICAgICAg ICAgICAgICAgICB8IGpvYi1zdGF0ZQ0Kam1Kb2JTdGF0ZVJlYXNvbnMxICAg ICAgICAgICAgICAgfCBqb2Itc3RhdGUtcmVhc29ucyAobm90ZSAxKQ0Kam1O dW1iZXJPZkludGVydmVuaW5nSm9icyAgICAgICAgfCBudW1iZXItb2YtaW50 ZXJ2ZW5pbmctam9icw0Kam1Kb2JLT2N0ZXRzUGVyQ29weVJlcXVlc3RlZCAg ICAgfCBqb2Itay1vY3RldHMNCmptSm9iS09jdGV0c1Byb2Nlc3NlZCAgICAg ICAgICAgIHwgam9iLWstb2N0ZXRzLXByb2Nlc3NlZA0Kam1Kb2JJbXByZXNz aW9uc1BlckNvcHlSZXF1ZXN0ZWQgfCBqb2ItaW1wcmVzc2lvbnMNCmptSm9i SW1wcmVzc2lvbnNDb21wbGV0ZWQgICAgICAgIHwgam9iLWltcHJlc3Npb25z LWNvbXBsZXRlZA0Kam1Kb2JPd25lciAgICAgICAgICAgICAgICAgICAgICAg fCBqb2Itb3JpZ2luYXRpbmctdXNlci1uYW1lDQoNCiBOb3RlczoNCiAtLS0t LS0NCiAgMS4gam1Kb2JTdGF0ZVJlYXNvbnMxIGlzIGEgYml0IG1hcCBkZXNj cmliZWQgaW4gb25lIG9iamVjdCBhbmQgdGhyZWUNCiAgICAgYXR0cmlidXRl cy4gIFRoZSBJUFAgY29uZGl0aW9uIG1heSBjaGFuZ2Ugb25lIG9yIG1vcmUg b2YgdGhlIGJpdHMNCiAgICAgaW4gb25lIG9yIG1vcmUgb2YgdGhlc2UgSm9i IE1JQiBpdGVtcy4NCg0KDQoNCkJlcmdtYW4gICAgICAgICAgICAgICAgICAg ICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDdd DQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3Rv Y29sIE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQoNCg0K NC40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBJUFANCg0KVGhl IGZvbGxvd2luZyBtYXBwaW5ncyBhcmUgcmVxdWlyZWQgaWYgdGhlIGxpc3Rl ZCBJUFAgam9iIHRlbXBsYXRlDQphdHRyaWJ1dGUgaXMgcHJvdmlkZWQuDQoN Ck1JQiBhdHRyaWJ1dGUgICAgICAgICAgICAgIHwgSVBQIGpvYiBhdHRyaWJ1 dGUgICAgICAgICAgICB8IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tDQpqb2JTdGF0ZVJlYXNvbnNOICAgICAgICAgICB8IGpvYi1z dGF0ZS1yZWFzb25zIChub3RlIDMpICAgfCBJbnRlZ2VyDQpqb2JDb2RlZENo YXJTZXQgICAgICAgICAgICB8IGF0dHJpYnV0ZXMtY2hhcnNldCAobm90ZSAx KSAgfCBPY3RldCBTdHJpbmcNCmpvYk5hdHVyYWxMYW5ndWFnZVRhZyAgICAg IHwgYXR0cmlidXRlcy1uYXR1cmFsLWxhbmd1YWdlICB8IE9jdGV0IFN0cmlu Zw0Kam9iVVJJICAgICAgICAgICAgICAgICAgICAgfCBqb2ItdXJpICAgICAg ICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JOYW1lICAgICAg ICAgICAgICAgICAgICB8IGpvYi1uYW1lICAgICAgICAgICAgICAgICAgICAg fCBPY3RldCBTdHJpbmcNCnBoeXNpY2FsRGV2aWNlICAgICAgICAgICAgIHwg b3V0cHV0LWRldmljZS1hc3NpZ25lZCAgICAgICB8IE9jdGV0IFN0cmluZw0K bnVtYmVyT2ZEb2N1bWVudHMgICAgICAgICAgfCBudW1iZXItb2YtZG9jdW1l bnRzICAgICAgICAgIHwgSW50ZWdlcg0Kam9iUHJpb3JpdHkgICAgICAgICAg ICAgICAgfCBqb2ItcHJpb3JpdHkgICAgICAgICAgICAgICAgIHwgSW50ZWdl cg0Kam9iSG9sZFVudGlsICAgICAgICAgICAgICAgfCBqb2ItaG9sZC11bnRp bCAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpzaWRlcyAgICAgICAg ICAgICAgICAgICAgICB8IHNpZGVzIChub3RlIDIpICAgICAgICAgICAgICAg fCBJbnRlZ2VyDQpmaW5pc2hpbmcgICAgICAgICAgICAgICAgICB8IGZpbmlz aGluZ3MgICAgICAgICAgICAgICAgICAgfCBJbnRlZ2VyDQpwcmludFF1YWxp dHlSZXF1ZXN0ZWQgICAgICB8IHByaW50LXF1YWxpdHkgICAgICAgICAgICAg ICAgfCBJbnRlZ2VyDQpwcmludGVyUmVzb2x1dGlvblJlcXVlc3RlZCB8IHBy aW50ZXItcmVzb2x1dGlvbiAgICAgICAgICAgfCBJbnRlZ2VyDQpqb2JDb3Bp ZXNSZXF1ZXN0ZWQgICAgICAgICB8IGNvcGllcyAobm90ZSA0KSAgICAgICAg ICAgICAgfCBJbnRlZ2VyDQpkb2N1bWVudENvcGllc1JlcXVlc3RlZCAgICB8 IGNvcGllcyAobm90ZSA0KSAgICAgICAgICAgICAgfCBJbnRlZ2VyDQpqb2JD b2xsYXRpb25UeXBlICAgICAgICAgICB8IG11bHRpcGxlLWRvY3VtZW50LWhh bmRsaW5nICAgfCBJbnRlZ2VyDQpzaGVldHNSZXF1ZXN0ZWQgICAgICAgICAg ICB8IGpvYi1tZWRpYS1zaGVldHMgICAgICAgICAgICAgfCBJbnRlZ2VyDQpz aGVldHNDb21wbGV0ZWQgICAgICAgICAgICB8IGpvYi1tZWRpYS1zaGVldHMt Y29tcGxldGVkICAgfCBJbnRlZ2VyDQptZWRpdW1SZXF1ZXN0ZWQgICAgICAg ICAgICB8IG1lZGlhICAgICAgICAgICAgICAgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCmpvYlN1Ym1pc3Npb25UaW1lICAgICAgICAgIHwgdGltZS1hdC1z dWJtaXNzaW9uICAgICAgICAgICB8IEludGVnZXINCmpvYlN0YXJ0ZWRQcm9j ZXNzaW5nVGltZSAgIHwgdGltZS1hdC1wcm9jZXNzaW5nICAgICAgICAgICB8 IEludGVnZXINCmpvYkNvbXBsZXRpb25UaW1lICAgICAgICAgIHwgdGltZS1h dC1jb21wbGV0ZWQgICAgICAgICAgICB8IEludGVnZXINCg0KIE5vdGVzOg0K IC0tLS0tLQ0KICAxLiBqb2JDb2RlZENoYXJTZXQgaXMgYW4gZW51bSBmcm9t IHRoZSBJQU5BIHJlZ2lzdHJ5IHdoaWNoIGlzIGFsc28NCiAgICAgdXNlZCBp biB0aGUgUHJpbnRlciBNSUIuICBUaGUgSVBQIGF0dHJpYnV0ZXMtY2hhcnNl dCBpcyB0aGUgbmFtZQ0KICAgICAoTUlNRSBwcmVmZXJyZWQgbmFtZSkgb2Yg dGhlIGNoYXJhY3RlciBzZXQuDQogIDIuIFRoZSBKb2IgTUlCIHNpZGVzIGF0 dHJpYnV0ZSB1c2VzIHRoZSBpbnRlZ2VyIHZhbHVlcyAiMSIgYW5kICIyIi4N CiAgICAgVGhlIElQUCBzaWRlcyBhdHRyaWJ1dGUgdXNlcyB0aHJlZSBrZXl3 b3Jkcy4NCiAgMy4gam9iU3RhdGVSZWFzb25zTiBpcyBhIGJpdCBtYXAgZGVz Y3JpYmVkIGluIG9uZSBvYmplY3QgYW5kIHRocmVlDQogICAgIGF0dHJpYnV0 ZXMuICBUaGUgSVBQIGNvbmRpdGlvbiBtYXkgY2hhbmdlIG9uZSBvciBtb3Jl IG9mIHRoZSBiaXRzDQogICAgIGluIG9uZSBvciBtb3JlIG9mIHRoZXNlIEpv YiBNSUIgaXRlbXMuDQogIDQuIFRoZSBJUFAgImNvcGllcyIgYXR0cmlidXRl IG1hcHMgdG8gdGhlIEpvYiBNSUI6DQogICAgICgxKSBqb2JDb3BpZXNSZXF1 ZXN0ZWQgd2hlbiB0aGUgam9iIGhhcyBvbmx5IG9uZSBkb2N1bWVudCBPUg0K ICAgICAgICAgSVBQICJtdWx0aXBsZS1kb2N1bWVudC1oYW5kbGluZyIgaXMg J3NpbmdsZS12YWx1ZWQnDQogICAgICgyKSBkb2N1bWVudENvcGllc1JlcXVl c3RlZCwgaW4gd2hpY2ggY2FzZSB0aGUgTUlCIHZhbHVlIGlzIHRoZQ0KICAg ICAgICAgdG90YWwgbnVtYmVyIG9mIGRvY3VtZW50IGNvcGllcyB0aGF0IHRo ZSBqb2Igd2lsbCBwcm9kdWNlIGFzIGENCiAgICAgICAgIHdob2xlLg0KDQoN Cg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSA4XQ0MDQpJTlRF Uk5FVC1EUkFGVCAgICAgICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBw aW5nICAgICAgICAgRmViIDUsIDE5OTgNCg0KDQoNCg0KNS4wICBJTlRFTExJ R0VOVCBQUklOVEVSIERBVEEgU1RSRUFNIChJUERTKQ0KDQpUaGUgSVBEUyBk YXRhc3RyZWFtIGZhY2lsaXRhdGVzIGEgY2xvc2UgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlIHByaW50DQpzdXBlcnZpc29yIChQcmludCBTZXJ2aWNlcyBG YWNpbGl0eSAtIFBTRikgYW5kIHRoZSBwcmludGVyLiAgVGhlcmUgYXJlDQpQ U0YgYXBwbGljYXRpb25zIGZvciBVTklYLCBXaW5kb3dzLCBPUy8yLCBPUy80 MDAgYW5kIGhvc3Qgb3BlcmF0aW5nDQpzeXN0ZW1zIHN1Y2ggYXMgVk0sIE1W UyBhbmQgVlNFLiBUb2dldGhlciwgUFNGIGFuZCBJUERTIHJlcHJlc2VudCBh DQpjb21wbGV0ZSwgbWF0dXJlIGFuZCByb2J1c3Qgam9iIG1hbmFnZW1lbnQg ZnJhbWV3b3JrIHdoaWNoIGluY2x1ZGVzIGZvbnQNCmFuZCByZXNvdXJjZSBt YW5hZ2VtZW50LCBwYWdlIHByb2dyZXNzIHRyYWNraW5nLCBqb2IgY2FuY2Vs bGF0aW9uLA0KY29tcGxldGUgZXJyb3IgcmVjb3ZlcnkgYW5kIGVuZC11c2Vy IG5vdGlmaWNhdGlvbi4gIEJlY2F1c2UgUFNGIGFuZCB0aGUNCnByaW50ZXIg Y29ycmVzcG9uZCB2aWEgdGhlIHVzZSBvZiBsb2NhbGx5IGFzc2lnbmVkIElE knMsIHRoZXJlIGlzIGENCmxpbWl0ZWQgYW1vdW50IG9mIGNsZWFyIHRleHQg aW5mb3JtYXRpb24gcHJvdmlkZWQgZHVyaW5nIHN1Ym1pc3Npb24gZm9yDQp1 c2UgYnkgdGhlIEpvYiBNSUIuDQoNCg0KNS4xICBqbUpvYlN1Ym1pc3Npb25J ZCBNYXBwZWQgdG8gSVBEUw0KDQpGb3IgSVBEUyBvbiB0aGUgTVZTIG9yIFZT RSBwbGF0Zm9ybToNCg0KICBvY3RldCAxOiAgICdFJw0KDQogIG9jdGV0cyAy LTQwOiAgQ29udGFpbnMgYnl0ZXMgMi0yNyBvZiB0aGUgWE9IIERlZmluZSBH cm91cCBCb3VuZGFyeQ0KICAgICAgICAgICAgICAgIEdyb3VwIElEIHRyaXBs ZXQuICBPY3RldCBwb3NpdGlvbiAyIG11c3QgY2FycnkgdGhlIHZhbHVlDQog ICAgICAgICAgICAgICAgeCcwMScuICBCeXRlcyAyOC00MCBtdXN0IGJlIGZp bGxlZCB3aXRoIHNwYWNlcy4NCg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlu cyBhIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRhdGlvbiBvZiB0 aGUNCiAgICAgICAgICAgICAgICAgam1Kb2JJbmRleCBhc3NpZ25lZCBieSB0 aGUgYWdlbnQuICBMZWFkaW5nIHplcm9zIHNoYWxsDQogICAgICAgICAgICAg ICAgIGJlIGluc2VydGVkIHRvIGZpbGwgdGhlIGVudGlyZSA4IG9jdGV0IGZp ZWxkLg0KDQoNCkZvciBJUERTIG9uIHRoZSBWTSBwbGF0Zm9ybToNCg0KICBv Y3RldCAxOiAgICdGJw0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgYnl0 ZXMgMi0zMSBvZiB0aGUgWE9IIERlZmluZSBHcm91cCBCb3VuZGFyeQ0KICAg ICAgICAgICAgICAgIEdyb3VwIElEIHRyaXBsZXQuICBPY3RldCBwb3NpdGlv biAyIG11c3QgY2FycnkgdGhlIHZhbHVlDQogICAgICAgICAgICAgICAgeCcw MicuICBCeXRlcyAzMi00MCBtdXN0IGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4N Cg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlucyBhIGRlY2ltYWwgKEFTQ0lJ IGNvZGVkKSByZXByZXNlbnRhdGlvbiBvZiB0aGUNCiAgICAgICAgICAgICAg ICAgam1Kb2JJbmRleCBhc3NpZ25lZCBieSB0aGUgYWdlbnQuICBMZWFkaW5n IHplcm9zIHNoYWxsDQogICAgICAgICAgICAgICAgIGJlIGluc2VydGVkIHRv IGZpbGwgdGhlIGVudGlyZSA4IG9jdGV0IGZpZWxkLg0KDQoNCkZvciBJUERT IG9uIHRoZSBPUy80MDAgcGxhdGZvcm06DQoNCiAgb2N0ZXQgMTogICAnRycN Cg0KICBvY3RldHMgMi00MDogIENvbnRhaW5zIGJ5dGVzIDItMzYgb2YgdGhl IFhPSCBEZWZpbmUgR3JvdXAgQm91bmRhcnkNCiAgICAgICAgICAgICAgICBH cm91cCBJRCB0cmlwbGV0LiAgT2N0ZXQgcG9zaXRpb24gMiBtdXN0IGNhcnJ5 IHRoZSB2YWx1ZQ0KICAgICAgICAgICAgICAgIHgnMDMnLiAgQnl0ZXMgMzct NDAgbXVzdCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuDQoNCiAgb2N0ZXRzIDQx LTQ4OiAgQ29udGFpbnMgYSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVz ZW50YXRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAgIGptSm9iSW5kZXgg YXNzaWduZWQgYnkgdGhlIGFnZW50LiAgTGVhZGluZyB6ZXJvcyBzaGFsbA0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9u YWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgOV0NDA0KSU5URVJORVQt RFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAg ICAgICAgIEZlYiA1LCAxOTk4DQoNCg0KDQoNCiAgICAgICAgICAgICAgICAg YmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0ZXQgZmllbGQu DQoNCg0KNS4yICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBJUERT DQoNCkZvciBNVlMvVlNFOg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAg ICAgICAgICAgfCBJUERTIFhPSCBER0IgR3JvdXAgSUQgfCBEYXRhIHR5cGUN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9iU291cmNlUGxhdGZv cm1UeXBlIHNwdE1WUyg3KSAgIHwgQnl0ZSAyID0geCcwMScgICAgICAgIHwg SW50ZWdlcg0Kam9iTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg Qnl0ZXMgNC0xMSAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KRm9y IFZNOg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICAgICAgICAgfCBJ UERTIFhPSCBER0IgR3JvdXAgSUQgfCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLQ0Kam9iU291cmNlUGxhdGZvcm1UeXBlIHNwdFZN KDgpICAgIHwgQnl0ZSAyID0geCcwMicgICAgICAgIHwgSW50ZWdlcg0KZmls ZU5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQnl0ZXMgNC0xMSAg ICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KRm9yIE9TLzQwMDoNCg0K TUlCIGF0dHJpYnV0ZSAgICAgICAgICAgICAgICAgICAgIHwgSVBEUyBYT0gg REdCIEdyb3VwIElEIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0NCmpvYlNvdXJjZVBsYXRmb3JtVHlwZSBzcHRPUzQwMCg5KSB8 IGJ5dGUgMiA9IHgnMDMnICAgICAgICB8IEludGVnZXINCmZpbGVOYW1lICAg ICAgICAgICAgICAgICAgICAgICAgICB8IEJ5dGVzIDIzLTMyICAgICAgICAg ICB8IE9jdGV0IFN0cmluZw0Kam9iTmFtZSAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgQnl0ZXMgMzctNDYgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5n DQoNCg0KDQo2LjAgIERPQ1VNRU5UIFBSSU5USU5HIEFQUExJQ0FUSU9OIChE UEEpDQoNClRoZSBJU08gMTAxNzUgRG9jdW1lbnQgUHJpbnRpbmcgQXBwbGlj YXRpb24gKERQQSkgW0RQQV0gc3VwcG9ydHMNCnByaW50aW5nIHVzaW5nIGFu eSBvbmUgb2YgdGhlIHRocmVlIHBvc3NpYmxlIGNvbmZpZ3VyYXRpb25zLiAg Rm9yDQpjb25maWd1cmF0aW9uIDIsIHRoZSBtYXBwaW5nIGRlZmluZWQgaGVy ZWluIGlzIHBlcmZvcm1lZCBvbiBhIHNlcnZlci4NCk90aGVyd2lzZSwgdGhl IG1hcHBpbmcgaXMgcGVyZm9ybWVkIG9uIGFuIGFnZW50IHdpdGhpbiB0aGUg cHJpbnRlci4NCg0KDQo2LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0 byBEUEENCg0KRFBBIGNvbnRhaW5zIGEgcmljaCBzZXQgb2YgcGFyYW1ldGVy cyB3aGljaCBhbGxvdyBzZXZlcmFsIG1ldGhvZHMgb2YNCmNyZWF0aW5nIHRo ZSBqbUpvYlN1Ym1pc3Npb25JRCBvYmplY3QuICBUbyBwcmV2ZW50IGludGVy b3BlcmFiaWxpdHkNCnByb2JsZW1zLCB0aGUgcHJlZmVycmVkIG1ldGhvZCBp cyB0byB1c2UgdGhlIERQQSBqb2Itb3JpZ2luYXRpbmctdXNlcg0KYXR0cmli dXRlIGFzIGZvbGxvd3M6DQoNCiAgb2N0ZXQgMTogICAnMCcNCg0KICBvY3Rl dHMgMi00MDogIENvbnRhaW5zIHRoZSBEUEEgam9iLW93bmVyIGF0dHJpYnV0 ZQ0KICAgICAgICAgICAgICAgIHN1cHBsaWVkIGJ5IHRoZSBzdWJtaXR0ZXIu ICBJZiB0aGUgam9iLW93bmVyDQogICAgICAgICAgICAgICAgaXMgbGVzcyB0 aGFuIDQwIG9jdGV0cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhl DQogICAgICAgICAgICAgICAgc3RyaW5nIHNoYWxsIGFwcGVhciBpbiBvY3Rl dCBwb3NpdGlvbiAyLiAgQW55IHVudXNlZA0KDQoNCg0KQmVyZ21hbiAgICAg ICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAg ICAgICAgW3BhZ2UgMTBdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBT dWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5 OA0KDQoNCg0KDQogICAgICAgICAgICAgICAgcG9ydGlvbiBvZiB0aGlzIGZp ZWxkIHNoYWxsIGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4NCiAgICAgICAgICAg ICAgICBPdGhlcndpc2UsIG9ubHkgdGhlIGxhc3QgMzkgYnl0ZXMgc2hhbGwg YmUgaW5jbHVkZWQuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgQ29udGFpbnMgYW4g OC1kaWdpdCBzZXF1ZW50aWFsIGRlY2ltYWwgbnVtYmVyLg0KDQoNCjYuMiAg am1Kb2JJbmRleCBNYXBwZWQgdG8gRFBBDQoNClRoZSBqb2IgaW5kZXggKGpt Sm9iSW5kZXgpIGFzc2lnbmVkIGJ5IHRoZSBTTk1QIGpvYiBtb25pdG9yaW5n IGFnZW50IGlzDQpyZXR1cm5lZCB0byB0aGUgY2xpZW50IGJ5IERQQSBhcyBh IGRlY2ltYWwgZGlnaXQgc3RyaW5nIGFzIHRoZSB2YWx1ZSBvZg0KdGhlIERQ QSBqb2ItaWRlbnRpZmllciBhdHRyaWJ1dGUuICAoU2luY2UgRFBBIGRvZXMg bm90IHJlcXVpcmUNCmNvbnNlY3V0aXZlbHkgZ2VuZXJhdGVkIGpvYi1pZGVu dGlmaWVycywgdGhlIGFnZW50IG1heSByZWNlaXZlIGpvYnMgZnJvbQ0KbXVs dGlwbGUgY2xpZW50cyBhbmQgY2FuIGFzc2lnbiB0aGUgam1Kb2JJbmRleCBp biBhbiBhc2NlbmRpbmcgc2VxdWVuY2UNCmluZGVwZW5kZW50IG9mIHRoZSBz dWJtaXR0aW5nIGpvYiBjbGllbnQuKSAgVGhlIERQQSBqb2ItaWRlbnRpZmll ciBtdXN0DQpiZSByZXN0cmljdGVkIHRvIHRoZSByYW5nZSBvZiAxIHRvIDk5 LDk5OSw5OTkgKGRlY2ltYWwpIHRvIGFsbG93IHRoZQ0KdmFsdWUgdG8gYmUg cHJvcGVybHkgcmVwcmVzZW50ZWQgaW4gam1Kb2JTdWJtaXNzaW9uSUQuDQoN Cg0KNi4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gRFBBDQoNCk1J QiBPYmplY3QgICAgICAgICAgICAgICAgICAgICAgIHwgRFBBIEpvYiBhdHRy aWJ1dGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmptSm9iU3RhdGUg ICAgICAgICAgICAgICAgICAgICAgIHwgam9iLXN0YXRlDQpqbUpvYlN0YXRl UmVhc29uczEgICAgICAgICAgICAgICB8IGpvYi1zdGF0ZS1yZWFzb25zIChu b3RlIDIpDQpqbU51bWJlck9mSW50ZXJ2ZW5pbmdKb2JzICAgICAgICB8IGlu dGVydmVuaW5nLWpvYnMNCmptSm9iS09jdGV0c1BlckNvcHlSZXF1ZXN0ZWQg ICAgIHwgdG90YWwtam9iLW9jdGV0cyAobm90ZXMgMSwgMykNCmptSm9iS09j dGV0c1Byb2Nlc3NlZCAgICAgICAgICAgIHwgam9iLW9jdGV0cy1jb21wbGV0 ZWQgKG5vdGUgMSkNCmptSm9iSW1wcmVzc2lvbnNQZXJDb3B5UmVxdWVzdGVk IHwgam9iLWltcHJlc3Npb24tY291bnQgKG5vdGUgMykNCmptSm9iSW1wcmVz c2lvbnNDb21wbGV0ZWQgICAgICAgIHwgaW1wcmVzc2lvbnMtY29tcGxldGVk DQpqbUpvYk93bmVyICAgICAgICAgICAgICAgICAgICAgICB8IGpvYi1vd25l cg0KDQogTm90ZXM6DQogLS0tLS0tDQogIDEuIGptSm9iS09jdGV0c1BlckNv cHlSZXF1ZXN0ZWQgYW5kIGptSm9iS09jdGV0c1Byb2Nlc3NlZCBpcyBpbiBL DQogICAgIG9jdGV0cyB3aGlsZSB0aGUgRFBBIGpvYi10b3RhbC1vY3RldHMg YW5kIGpvYi1vY3RldHMtY29tcGxldGVkIGlzDQogICAgIGluIG9jdGV0cyBh bmQgaXMgNjMtYml0cyBvZiBzaWduaWZpY2FuY2UuDQogIDIuIGpvYlN0YXRl UmVhc29uc04gaXMgYSBiaXQgbWFwIGRlc2NyaWJlZCBpbiBvbmUgb2JqZWN0 IGFuZCB0aHJlZQ0KICAgICBhdHRyaWJ1dGVzLiAgVGhlIERQQSBjb25kaXRp b24gbWF5IGNoYW5nZSBvbmUgb3IgbW9yZSBvZiB0aGUgYml0cw0KICAgICBp biBvbmUgb3IgbW9yZSBvZiB0aGVzZSBKb2IgTUlCIGl0ZW1zLiAgQWxzbyB0 aGUgRFBBDQogICAgIGpvYi1zdGF0ZS1yZWFzb25zIGlzIGEgbXVsdGktdmFs dWVkIGF0dHJpYnV0ZSB3aXRoIGVhY2ggdmFsdWUgYmVpbmcNCiAgICAgYW4g T0JKRUNUIElERU5USUZJRVIgKE9JRCkuDQogIDMuIERQQSBvY3RldHMgaW5j bHVkZSB0aGUgbXVsdGlwbGljYXRpb24gZmFjdG9yIGR1ZSB0byBqb2IgYW5k DQogICAgIGRvY3VtZW50IGNvcGllcywgd2hpbGUgdGhlIE1JQiB2YWx1ZXMg ZG8gbm90Lg0KDQoNCjYuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQg dG8gRFBBDQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVk IGlmIHRoZSBsaXN0ZWQgRFBBIGpvYiBhdHRyaWJ1dGUgaXMNCnByb3ZpZGVk Lg0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTFdDQwN CklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29s IE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQpNSUIgYXR0 cmlidXRlICAgICAgICAgICAgICB8IERQQSBqb2IgYXR0cmlidXRlICAgICAg ICAgICAgfElQUCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLQ0Kam9iU3RhdGVSZWFzb25zTiAgICAgICAgICAgfCBqb2Itc3RhdGUt cmVhc29ucyAobm90ZSAyKSAgIHwgSW50ZWdlcg0Kam9iQ29kZWRDaGFyU2V0 ICAgICAgICAgICAgfCAobm90ZSAxKSAgICAgICAgICAgICAgICAgICAgIHwg T2N0ZXQgU3RyaW5nDQpqb2JBY2NvdW50TmFtZSAgICAgICAgICAgICB8IGFj Y291bnRpbmctaW5mb3JtYXRpb24gICAgICAgfCBPY3RldCBTdHJpbmcNCmpv Yk5hbWUgICAgICAgICAgICAgICAgICAgIHwgam9iLW5hbWUgICAgICAgICAg ICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KZGV2aWNlTmFtZVJlcXVlc3Rl ZCAgICAgICAgfCBwcmludGVyLW5hbWUtcmVxdWVzdGVkICAgICAgIHwgT2N0 ZXQgU3RyaW5nDQpwaHlzaWNhbERldmljZSAgICAgICAgICAgICB8IHByaW50 ZXJzLWFzc2lnbmVkICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCm51bWJl ck9mRG9jdW1lbnRzICAgICAgICAgIHwgbnVtYmVyLW9mLWRvY3VtZW50cyAg ICAgICAgICB8IEludGVnZXINCmZpbGVOYW1lICAgICAgICAgICAgICAgICAg IHwgZmlsZS1uYW1lICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmlu Zw0KZG9jdW1lbnROYW1lICAgICAgICAgICAgICAgfCBkb2N1bWVudC1uYW1l ICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JDb21tZW50ICAg ICAgICAgICAgICAgICB8IGpvYi1jb21tZW50ICAgICAgICAgICAgICAgICAg fCBPY3RldCBTdHJpbmcNCmRvY3VtZW50Rm9ybWF0ICAgICAgICAgICAgIHwg ZG9jdW1lbnQtZm9ybWF0ICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0K am9iUHJpb3JpdHkgICAgICAgICAgICAgICAgfCBqb2ItcHJpb3JpdHkgICAg ICAgICAgICAgICAgIHwgSW50ZWdlcg0Kam9iUHJvY2Vzc0FmdGVyRGF0ZUFu ZFRpbWUgfCBqb2ItcHJpbnQtYWZ0ZXIgICAgICAgICAgICAgIHwgT2N0ZXQg U3RyaW5nDQpvdXRwdXRCaW4gICAgICAgICAgICAgICAgICB8IHJlc3VsdHMt cHJvZmlsZS5vdXRwdXQtYmluICAgfCBPY3RldCBTdHJpbmcNCnNpZGVzICAg ICAgICAgICAgICAgICAgICAgIHwgc2lkZXMgKG5vdGUgMykgICAgICAgICAg ICAgICB8IEludGVnZXINCmZpbmlzaGluZyAgICAgICAgICAgICAgICAgIHwg am9iLWZpbmlzaGluZywgZmluaXNoaW5nICAgICB8IEludGVnZXINCnByaW50 UXVhbGl0eVJlcXVlc3RlZCAgICAgIHwgcHJpbnQtcXVhbGl0eSAgICAgICAg ICAgICAgICB8IEludGVnZXINCnByaW50ZXJSZXNvbHV0aW9uUmVxdWVzdGVk IHwgZGVmYXVsdC1wcmludGVyLXJlc29sdXRpb24gICB8IEludGVnZXINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChub3RlIDQpICAgICAgICAg ICAgICAgICAgICB8DQpqb2JDb3BpZXNSZXF1ZXN0ZWQgICAgICAgICB8IHJl c3VsdHMtcHJvZmlsZS5qb2ItY29waWVzICAgfCBJbnRlZ2VyDQpqb2JDb3Bp ZXNDb21wbGV0ZWQgICAgICAgICB8IGpvYi1jb3BpZXMtY29tcGxldGVkICAg ICAgICAgfCBJbnRlZ2VyDQpkb2N1bWVudENvcGllc1JlcXVlc3RlZCAgICB8 IGNvcHktY291bnQgKG5vdGUgNSkgICAgICAgICAgfCBJbnRlZ2VyDQpkb2N1 bWVudENvcGllc0NvbXBsZXRlZCAgICB8IGNvcGllcy1jb21wbGV0ZWQgKG5v dGUgNikgICAgfCBJbnRlZ2VyDQpzaGVldHNSZXF1ZXN0ZWQgICAgICAgICAg ICB8IGpvYi1tZWRpYS1zaGVldC1jb3VudCAgICAgICAgfCBJbnRlZ2VyDQpz aGVldHNDb21wbGV0ZWQgICAgICAgICAgICB8IGpvYi1tZWRpYS1zaGVldHMt Y29tcGxldGVkICAgfCBJbnRlZ2VyDQpwYWdlc1JlcXVlc3RlZCAgICAgICAg ICAgICB8IGpvYi1wYWdlLWNvdW50ICAgICAgICAgICAgICAgfCBJbnRlZ2Vy DQpwYWdlc0NvbXBsZXRlZCAgICAgICAgICAgICB8IHBhZ2VzLWNvbXBsZXRl ZCAgICAgICAgICAgICAgfCBJbnRlZ2VyDQptZWRpdW1SZXF1ZXN0ZWQgICAg ICAgICAgICB8IHBhZ2UtbWVkaWEtc2VsZWN0LCAgICAgICAgICAgfCBPY3Rl dCBTdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIGRlZmF1 bHQtbWVkaXVtICAgICAgICAgICAgICB8DQpqb2JTdWJtaXNzaW9uVGltZSAg ICAgICAgICB8IHN1Ym1pc3Npb24tdGltZSAobm90ZSA3KSAgICAgfCBPY3Rl dCBTdHJpbmcNCmpvYlN0YXJ0ZWRQcm9jZXNzaW5nVGltZSAgIHwgc3RhcnRl ZC1wcmludGluZy10aW1lIChub3RlIDcpIE9jdGV0IFN0cmluZw0Kam9iQ29t cGxldGlvblRpbWUgICAgICAgICAgfCBjb21wbGV0aW9uLXRpbWUgKG5vdGUg NykgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCiBOb3RlczoNCiAtLS0tLS0NCiAg MS4gRXZlcnkgRFBBIGF0dHJpYnV0ZSBpcyB0YWdnZWQgaW5kaWNhdGluZyB0 aGUgY29kZWQgY2hhcmFjdGVyIHNldA0KICAgICB0byBiZSB1c2VkIGZvciB0 aGF0IGF0dHJpYnV0ZS4NCiAgMi4gam9iU3RhdGVSZWFzb25zTiBpcyBhIGJp dCBtYXAgZGVzY3JpYmVkIGluIG9uZSBvYmplY3QgYW5kIHRocmVlDQogICAg IGF0dHJpYnV0ZXMuICBUaGUgRFBBIGNvbmRpdGlvbiBtYXkgY2hhbmdlIG9u ZSBvciBtb3JlIG9mIHRoZSBiaXRzDQogICAgIGluIG9uZSBvciBtb3JlIG9m IHRoZXNlIEpvYiBNSUIgaXRlbXMuICBBbHNvIHRoZSBEUEENCiAgICAgam9i LXN0YXRlLXJlYXNvbnMgaXMgYSBtdWx0aS12YWx1ZWQgYXR0cmlidXRlIHdp dGggZWFjaCB2YWx1ZSBiZWluZw0KICAgICBhbiBPQkpFQ1QgSURFTlRJRklF UiAoT0lEKS4NCiAgMy4gVGhlIEpvYiBNSUIgc2lkZXMgYXR0cmlidXRlIGlz IGFuIGludGVnZXIgJzEnIG9yICcyJyB3aGlsZSB0aGUgRFBBDQogICAgIHNp ZGVzIGF0dHJpYnV0ZSBoYXMgb25lIG9mIHNpeCBPSUQgdmFsdWVzIHRoYXQg aW5jbHVkZXMgcGxleC4NCiAgNC4gcHJpbnRlclJlc29sdXRpb25SZXF1ZXN0 ZWQgaGFzIHggYW5kIHkgcmVzb2x1dGlvbiBhbmQgaXMgaW50ZW5kZWQNCiAg ICAgdG8gb3ZlcnJpZGUgdGhlIHJlc29sdXRpb24gaW5zdHJ1Y3Rpb24gaW4g dGhlIGRvY3VtZW50LCBpZiBhbnksDQogICAgIHdoaWxlIHRoZSBEUEEgZGVm YXVsdC1wcmludGVyLXJlc29sdXRpb24gaXMgdGhlIHNhbWUgaW4geCBhbmQg eSBhbmQNCiAgICAgb25seSB0YWtlcyBlZmZlY3QgaWYgdGhlIGRvY3VtZW50 IGRvZXMgbm90IGNvbnRhaW4gYSByZXNvbHV0aW9uDQogICAgIGluc3RydWN0 aW9uDQogIDUuIFRoZSBEUEEgImNvcHktY291bnQiIGF0dHJpYnV0ZSBpcyBh IHBlci1kb2N1bWVudCBhdHRyaWJ1dGUsIHNvIHRoZQ0KDQoNCg0KQmVyZ21h biAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAg ICAgICAgICAgICAgW3BhZ2UgMTJdDQwNCklOVEVSTkVULURSQUZUICAgICAg IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIg NSwgMTk5OA0KDQoNCg0KDQogICAgIE1JQiB2YWx1ZSBpcyB0aGUgc3VtIG9m IHRoZSBkb2N1bWVudHMnICJjb3B5LWNvdW50IiB2YWx1ZXMgdGltZXMNCiAg ICAgdGhlIGpvYidzICJyZXN1bHRzLXByb2ZpbGUuam9iLWNvcGllcyIgdmFs dWUuDQogIDYuIFRoZSBEUEEgImNvcGllcy1jb21wbGV0ZWQiIGF0dHJpYnV0 ZSBpcyBhIHBlci1kb2N1bWVudCBhdHRyaWJ1dGUsDQogICAgIHNvIHRoZSBN SUIgdmFsdWUgaXMgdGhlIHN1bSBvZiB0aGUgZG9jdW1lbnRzJyAiY29waWVz LWNvbXBsZXRlZCINCiAgICAgdmFsdWVzIHRpbWVzIHRoZSBqb2IncyAicmVz dWx0cy1wcm9maWxlLmpvYi1jb3BpZXMiIHZhbHVlLg0KICA3LiBUaGUgRFBB IEdlbmVyYXRsaXplZFRpbWUgZGF0YSB0eXBlIGlzIGRlZmluZWQgYnkgSVNP IDg4MjQNCiAgICAgKElTTy04ODI0KSB3aGlsZSB0aGUgTUlCIERhdGVBbmRU aW1lIGlzIGRlZmluZWQgYnkgU05NUHYyLVRDLg0KDQoNCg0KNy4wICBOT1ZF TEwgRElTVFJJQlVURUQgUFJJTlQgU0VSVklDRSAoTkRQUykNCg0KTm92ZWxs IERpc3RyaWJ1dGVkIFByaW50IFNlcnZpY2VzIGlzIGEgRFBBIGJhc2VkIGpv YiBzdWJtaXNzaW9uIHByb3RvY29sDQp0aGF0IGNvbmZvcm1zIHRvIGNvbmZp Z3VyYXRpb24gMy4NCg0KDQo3LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBl ZCB0byBORFBTDQoNCk5EUFMgc3VwcG9ydHMgdGhlIGdlbmVyYXRpb24gb2Yg YSBwcm9wZXJseSBmb3JtYXR0ZWQgam1Kb2JTdWJtaXNzaW9uSUQNCmZvciB1 c2UgaW4gdGhlIEpvYiBNSUIsIHZpYSB0aGUgYXR0cmlidXRlIG5kcHMtYXR0 LWpvYi1pZGVudGlmaWVyLg0KDQpJU1NVRTogSXMgdGhpcyB0aGUgcHJvcGVy IE5EUFMgYXR0cmlidXRlIG9yIHNob3VsZCB0aGUgYXR0cmlidXRlIG5kcHMt DQphdHQtaWRlbnRpZmllci1vbi1jbGllbnQgb3IgbmRwcy1hdHQtbmV3LWpv Yi1pZGVudGlmaWVyIHRvIGJlIHVzZWQ/DQoNCg0KNy4yICBqbUpvYkluZGV4 IE1hcHBlZCB0byBORFBTDQoNCk5EUFMgZGVmaW5lcyB0aGUgYXR0cmlidXRl IG5kcHMtYXR0LWpvYi1pZGVudGlmaWVyLW9uLXByaW50ZXIgdGhhdCBjYW4N CmJlIHVzZWQgdG8gcmV0dXJuIHRoZSB2YWx1ZSBvZiBqbUpvYkluZGV4IHRv IHRoZSBORFBTIGNsaWVudC4NCg0KDQo3LjMgIE90aGVyIE1JQiBPYmplY3Rz IE1hcHBlZCB0byBORFBTDQoNCk1JQiBPYmplY3QgICAgICAgICAgICAgICAg ICAgICAgIHwgTkRQUyBQYXJhbWV0ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0Kam1Kb2JTdGF0ZSAgICAgICAgICAgICAgICAgICAgICAgfCBu ZHBzLWF0dC1jdXJyZW50LWpvYi1zdGF0ZSAobm90ZSAxKQ0Kam1Kb2JTdGF0 ZVJlYXNvbnMxICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2Itc3RhdGUt cmVhc29ucyAobm90ZSAyKQ0Kam1OdW1iZXJPZkludGVydmVuaW5nSm9icyAg ICAgICAgfCBuZHBzLWF0dC1pbnRlcnZlbmluZy1qb2JzDQpqbUpvYktPY3Rl dHNQZXJDb3B5UmVxdWVzdGVkICAgICB8IG5kcHMtYXR0LXRvdGFsLWpvYi1v Y3RldHMgKG5vdGVzIDMsNCkNCmptSm9iS09jdGV0c1Byb2Nlc3NlZCAgICAg ICAgICAgIHwgbmRwcy1hdHQtb2N0ZXRzLWNvbXBsZXRlZCAobm90ZSAzKQ0K am1Kb2JJbXByZXNzaW9uc1BlckNvcHlSZXF1ZXN0ZWQgfCBuZHBzLWF0dC1q b2ItaW1wcmVzc2lvbnMtY291bnQNCmptSm9iSW1wcmVzc2lvbnNDb21wbGV0 ZWQgICAgICAgIHwgbmRwcy1hdHQtaW1wcmVzc2lvbnMtY29tcGxldGVkDQpq bUpvYk93bmVyICAgICAgICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LWpv Yi1vd25lciAobm90ZSA1KQ0KDQogTm90ZXM6DQogLS0tLS0tDQogIDEuIFNv bWUgb2YgdGhlIE5EUFMgam9iIHN0YXRlcyBtdXN0IGJlIHJlcHJlc2VudGVk IGJ5IGJvdGggYQ0KICAgICBqbUpvYlN0YXRlIGFuZCBhIGptSm9iU3RhdGVS ZWFzb25zMSBvYmplY3Qgb3IgYSBqb2JTdGF0ZVJlYXNvbnNODQogICAgIGF0 dHJpYnV0ZS4NCiAgMi4gVGhlIE5EUFMgam9iIHN0YXRlIHJlYXNvbnMgbWF5 IGJlIG1hcHBlZCB0byBlaXRoZXIgdGhlIG9iamVjdA0KICAgICBqbUpvYlN0 YXRlUmVhc29uczEgb3IgdGhlIGF0dHJpYnV0ZSBqb2JTdGF0ZVJlYXNvbnNO Lg0KICAzLiBqbUpvYktPY3RldHNQZXJDb3B5UmVxdWVzdGVkIGFuZCBqbUpv YktPY3RldHNQcm9jZXNzZWQgaXMgaW4gSw0KDQoNCg0KQmVyZ21hbiAgICAg ICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAg ICAgICAgW3BhZ2UgMTNdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBT dWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5 OA0KDQoNCg0KDQogICAgIG9jdGV0cyB3aGlsZSB0aGUgTkRQUyBuZHBzLWF0 dC1qb2ItdG90YWwtb2N0ZXRzIGFuZA0KICAgICBuZHBzLWF0dC1qb2Itb2N0 ZXRzLWNvbXBsZXRlZCBpcyBpbiBvY3RldHMgYW5kIGlzIDYzLWJpdHMgb2YN CiAgICAgc2lnbmlmaWNhbmNlLg0KICA0LiBORFBTIG9jdGV0cyBpbmNsdWRl IHRoZSBtdWx0aXBsaWNhdGlvbiBmYWN0b3IgZHVlIHRvIGpvYiBhbmQNCiAg ICAgZG9jdW1lbnQgY29waWVzLCB3aGlsZSB0aGUgTUlCIHZhbHVlcyBkbyBu b3QuDQogIDUuIFRoZSBKb2IgTUlCIG9iamVjdCBtdXN0IGJlIG11bHRpcGxp ZWQgYnkgdGhlIGF0dHJpYnV0ZQ0KICAgICBqb2JDb3BpZXNSZXF1ZXN0ZWQg dG8gb2J0YWluIHRoZSBORFBTIGF0dHJpYnV0ZSB2YWx1ZSwgaWYgbXVsdGlw bGUNCiAgICAgY29waWVzIGhhdmUgYmVlbiByZXF1ZXN0ZWQuDQoNCjcuNCAg VGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gTkRQUw0KDQpUaGUgZm9s bG93aW5nIG1hcHBpbmdzIGFyZSByZXF1aXJlZCBpZiB0aGUgbGlzdGVkIFBK TCBhdHRyaWJ1dGUgb3INCmNvbW1hbmQgb3B0aW9uIGlzIHByb3ZpZGVkLg0K DQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IE5EUFMgcGFyYW1ldGVy ICAgICAgICAgICAgICAgfCBEYXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLQ0Kam9iQWNjb3VudE5hbWUgICAgICAgICAgICAgfCBuZHBz LWF0dC1qb2Itb3duZXIgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JO YW1lICAgICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LWpvYi1uYW1lICAg ICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmpvYk9yaWdpbmF0aW5nSG9zdCAg ICAgICAgIHwgbmRwcy1hdHQtam9iLW9yaWdpbmF0b3IgICAgICB8IE9jdGV0 IFN0cmluZw0KZGV2aWNlTmFtZVJlcXVlc3RlZCAgICAgICAgfCBuZHBzLWF0 dC1wcmludGVyLW5hbWUtLSAgICAgIHwgT2N0ZXQgU3RyaW5nDQogICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICByZXF1ZXN0ZWQgICAgICAgICAgICAg ICAgICAgfA0KbnVtYmVyT2ZEb2N1bWVudHMgICAgICAgICAgfCBuZHBzLWF0 dC1udW1iZXItb2YtZG9jdW1lbnRzIHwgSW50ZWdlcg0KZmlsZU5hbWUgICAg ICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1kb2N1bWVudC1maWxlLW5hbWUg IHwgT2N0ZXQgU3RyaW5nDQpkb2N1bWVudE5hbWUgICAgICAgICAgICAgICB8 IG5kcHMtYXR0LWRvY3VtZW50LW5hbWUgICAgICAgfCBPY3RldCBTdHJpbmcN CmpvYkNvbW1lbnQgICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQtam9iLWNv bW1lbnQgICAgICAgICB8IE9jdGV0IFN0cmluZw0KZG9jdW1lbnRGb3JtYXRJ bmRleCAgICAgICAgfCBuZHBzLWF0dC1wcnRJbnRlcnByZXRlckluZGV4IHwg SW50ZWdlcg0KZG9jdW1lbnRGb3JtYXQgICAgICAgICAgICAgfCBuZHBzLWF0 dC1kb2N1bWVudC1mb3JtYXQgICAgIHwgSW50ZWdlcg0Kam9iUHJpb3JpdHkg ICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2ItcHJpb3JpdHkgICAgICAg IHwgSW50ZWdlcg0Kam9iUHJvY2Vzc0FmdGVyRGF0ZUFuZFRpbWUgfCBuZHBz LWF0dC1qb2ItcHJpbnQtYWZ0ZXIgICAgIHwgT2N0ZXQgU3RyaW5nDQpvdXRw dXRCaW4gICAgICAgICAgICAgICAgICB8IG5kcHMtYXR0LXJlc3VsdHMtcHJv ZmlsZSAgICAgfCBJbnRlZ2VyDQogICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAobm90ZSAxKSAgICAgICAgICAgICAgICAgICAgfA0Kc2lkZXMgICAg ICAgICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1zaWRlcyAobm90ZSAyKSAg ICAgIHwgSW50ZWdlcg0KZmluaXNoaW5nICAgICAgICAgICAgICAgICAgfCBu ZHBzLWF0dC1qb2ItZmluaXNoaW5nICAgICAgIHwgSW50ZWdlcg0KcHJpbnRR dWFsaXR5UmVxdWVzdGVkICAgICAgfCBuZHBzLWF0dC1wcmludC1xdWFsaXR5 ICAgICAgIHwgSW50ZWdlcg0KcHJpbnRlclJlc29sdXRpb25SZXF1ZXN0ZWQg fCBuZHBzLWF0dC1kZWZhdWx0LXByaW50ZXItLSAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIHJlc29sdXRpb24gKG5vdGUgMykgICAgICAg ICB8IEludGVnZXINCnByaW50ZXJSZXNvbHV0aW9uVXNlZCAgICAgIHwgbmRw cy1hdHQtZGVmYXVsdC1yZXNvbHV0aW9ucy0tDQogICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICB1c2VkICAgICAgICAgICAgICAgICAgICAgICAgfCBJ bnRlZ2VyDQpqb2JDb3BpZXNSZXF1ZXN0ZWQgICAgICAgICB8IG5kcHMtYXR0 LXJlc3VsdHMtcHJvZmlsZSAgICAgfCBJbnRlZ2VyDQogICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAobm90ZSA0KSAgICAgICAgICAgICAgICAgICAg fA0Kam9iQ29waWVzQ29tcGxldGVkICAgICAgICAgfCBuZHBzLWF0dC1qb2It Y29waWVzLWNvbXBsZXRlZHwgSW50ZWdlcg0KZG9jdW1lbnRDb3BpZXNSZXF1 ZXN0ZWQgICAgfCBuZHBzLWF0dC1jb3B5LWNvdW50ICAgICAgICAgIHwgSW50 ZWdlcg0KZG9jdW1lbnRDb3BpZXNDb21wbGV0ZWQgICAgfCBuZHBzLWF0dC1j b3BpZXMtY29tcGxldGVkICAgIHwgSW50ZWdlcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgKG5vdGUgMykgICAgICAgICAgICAgICAgICAgIHwN CnNoZWV0c1JlcXVlc3RlZCAgICAgICAgICAgIHwgbmRwcy1hdHQtam9iLW1l ZGlhLS0gICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICBzaGVldC1jb3VudCAgICAgICAgICAgICAgICAgfCBJbnRlZ2VyDQpzaGVl dHNDb21wbGV0ZWQgICAgICAgICAgICB8IG5kcHMtYXR0LW1lZGlhLXNoZWV0 cy0tICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgY29t cGxldGVkICAgICAgICAgICAgICAgICAgIHwgSW50ZWdlcg0KbWVkaXVtQ29u c3VtZWQgICAgICAgICAgICAgfCBuZHBzLWF0dC1tZWRpYS11c2VkICAgICAg ICAgIHwgSW50ZWdlcg0Kam9iU3VibWlzc2lvblRvU2VydmVyVGltZSAgfCBu ZHBzLWF0dC1zdWJtaXNzaW9uLXRpbWUgICAgIHwgT2N0ZXQgU3RyaW5nDQpq b2JTdWJtaXNzaW9uVGltZSAgICAgICAgICB8IG5kcHMtYXR0LXN0YXJ0ZWQt cHJpbnRpbmctdGltZSBPY3RldCBTdHJpbmcNCmpvYkNvbXBsZXRpb25UaW1l ICAgICAgICAgIHwgbmRwcy1hdHQtY29tcGxldGlvbi10aW1lICAgICB8IE9j dGV0IFN0cmluZw0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAg IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTRd DQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3Rv Y29sIE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQoNCiBO b3RlczoNCiAtLS0tLS0NCiAgMS4gVGhlIG91dHB1dC1iaW4gZmllbGQgaW4g bmRwcy1hdHQtcmVzdWx0cy1wcm9maWxlIGlzIHRvIGJlIHVzZWQuDQogIDIu IFRoZSBKb2IgTUlCIHNpZGVzIGF0dHJpYnV0ZSBpcyBhbiBpbnRlZ2VyICcx JyBvciAnMicgd2hpbGUgdGhlIE5EUFMNCiAgICAgc2lkZXMgYXR0cmlidXRl IGhhcyBvbmUgb2Ygc2l4IE9JRCB2YWx1ZXMgdGhhdCBpbmNsdWRlcyBwbGV4 Lg0KICAzLiBwcmludGVyUmVzb2x1dGlvblJlcXVlc3RlZCBoYXMgeCBhbmQg eSByZXNvbHV0aW9uIGFuZCBpcyBpbnRlbmRlZA0KICAgICB0byBvdmVycmlk ZSB0aGUgcmVzb2x1dGlvbiBpbnN0cnVjdGlvbiBpbiB0aGUgZG9jdW1lbnQs IGlmIGFueSwNCiAgICAgd2hpbGUgdGhlIG5kcHMtYXR0LWRlZmF1bHQtcHJp bnRlci1yZXNvbHV0aW9uIGlzIHRoZSBzYW1lIGluIHggYW5kDQogICAgIHkg YW5kIG9ubHkgdGFrZXMgZWZmZWN0IGlmIHRoZSBkb2N1bWVudCBkb2VzIG5v dCBjb250YWluIGENCiAgICAgcmVzb2x1dGlvbiBpbnN0cnVjdGlvbg0KICA0 LiBUaGUgam9iLWNvcGllcyBmaWVsZCBpbiBuZHBzLWF0dC1yZXN1bHRzLXBy b2ZpbGUgaXMgdG8gYmUgdXNlZC4NCg0KDQoNCjguMCAgUFJJTlRFUiBKT0Ig TEFOR1VBR0UgKFBKTCkNCg0KUEpMIFtQSkxdIGhhcyBiZWVuIGRldmVsb3Bl ZCBieSBIZXdsZXR0LVBhY2thcmQgdG8gcHJvdmlkZSBqb2IgY29udHJvbA0K aW5mb3JtYXRpb24gdG8gdGhlIHByaW50ZXIgYW5kIHN0YXR1cyBpbmZvcm1h dGlvbiB0byBhcHBsaWNhdGlvbnMsDQppbmRlcGVuZGVudCBvZiB0aGUgUERM Lg0KDQoNCjguMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFBKTA0K DQpQSkwgaGFzIGRlZmluZWQgdGhlIFNVQk1JU1NJT05JRCBvcHRpb24gZm9y IHRoZSBKT0IgY29tbWFuZCB3aGljaA0KaW5kaWNhdGVzIGEgcHJvcGVybHkg Zm9ybWF0dGVkIGptSm9iU3VibWlzc2lvbklEIGZvciB1c2UgaW4gdGhlIEpv YiBNSUIuDQpUaGUgUEpMIEpPQiBjb21tYW5kIGlzIHByZXNlbnRlZCBhdCB0 aGUgc3RhcnQgb2YgYSBwcmludCBqb2Igd2l0aA0Kb3B0aW9ucyB0aGF0IGFw cGx5IG9ubHkgdGhlIGF0dGFjaGVkIGpvYi4gIFRoZSBzeW50YXggZm9yIHRo aXMgY29tbWFuZA0Kb3B0aW9uIGlzOg0KDQogICAgICBAUEpMIEpPQiBTVUJN SVNTSU9OSUQgPSAiaWQgc3RyaW5nIg0KDQpEcml2ZXIgc29mdHdhcmUgdGhh dCBpbXBsZW1lbnRzIHRoaXMgUEpMIGNvbW1hbmQgb3B0aW9uIG11c3QgcHJv dmlkZSB0aGUNCiJpZCBzdHJpbmciIGluIG9uZSBvZiB0aGUgY2xpZW50IHZl cnNpb24gZm9ybWF0cyBzcGVjaWZpZWQgaW4gdGhlIEpvYg0KTUlCIGZvciBq bUpvYlN1Ym1pc3Npb25JRC4NCg0KRm9yIGRyaXZlcnMgdGhhdCBhcmUgbm90 IGFibGUgdG8gY3JlYXRlIHRoZSBTVUJNSVNTSU9OSUQgb3B0aW9uLCBpdCBp cw0KcmVjb21tZW5kZWQgdGhhdCBqbUpvYlN1Ym1pc3Npb25JRCBmb3JtYXQg MCBiZSBjcmVhdGVkIGJ5IHRoZSBhZ2VudA0KdXNpbmcgdGhlIFBKTCBhdHRy aWJ1dGUgRG9jT3duZXIgb3IgRG9jT3duZXJJZC4NCg0KICBvY3RldCAxOiAg ICcwJw0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIHN0cmluZyBh c3NvY2lhdGVkIHdpdGggRG9jT3duZXIgb3INCiAgICAgICAgICAgICAgICBE b2NPd25lcklkLiAgSWYgdGhlIHN0cmluZyBpcyBsZXNzIHRoYW4gNDAgb2N0 ZXRzLCB0aGUNCiAgICAgICAgICAgICAgICBsZWZ0LW1vc3QgY2hhcmFjdGVy IGluIHRoZSBzdHJpbmcgc2hhbGwgYXBwZWFyIGluIG9jdGV0DQogICAgICAg ICAgICAgICAgcG9zaXRpb24gMi4gIE90aGVyd2lzZSwgb25seSB0aGUgbGFz dCAzOSBieXRlcyBzaGFsbCBiZQ0KICAgICAgICAgICAgICAgIGluY2x1ZGVk LiAgQW55IHVudXNlZCBwb3J0aW9uIG9mIHRoaXMgZmllbGQgc2hhbGwgYmUN CiAgICAgICAgICAgICAgICBmaWxsZWQgd2l0aCBzcGFjZXMuICBJZiBEb2NP d25lciBvciBEb2NPd25lcklkIGNhbm5vdCBiZQ0KICAgICAgICAgICAgICAg IG9idGFpbmVkLCB0aGlzIGZpZWxkIHNoYWxsIGJlIGJsYW5rLg0KDQoNCg0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9u YWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTVdDQwNCklOVEVSTkVU LURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg ICAgICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQogIG9jdGV0cyA0MS00ODog IENvbnRhaW5zIHRoZSB2YWx1ZSBvZiBqbUpvYkluZGV4IGFzc29jaWF0ZWQg d2l0aCB0aGUNCiAgICAgICAgICAgICAgICAgam9iLiAgTGVhZGluZyB6ZXJv cyBzaGFsbCBiZSBpbnNlcnRlZCB0byBmaWxsIHRoZQ0KICAgICAgICAgICAg ICAgICBlbnRpcmUgOCBvY3RldCBmaWVsZC4NCg0KDQo4LjIgIGptSm9iSW5k ZXggTWFwcGVkIHRvIFBKTA0KDQpQSkwgZG9lcyBub3QgcHJvdmlkZSBhIHZh bHVlIHRoYXQgY2FuIGJlIG1hcHBlZCB0byBqbUpvYkluZGV4Lg0KDQoNCjgu MyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVkIHRvIFBKTA0KDQpNSUIgT2Jq ZWN0ICAgICAgICAgICAgfCBQSkwgSm9iIGF0dHJpYnV0ZQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCmpvYk93bmVyICAgICAgICAgICAgICB8IERvY093bmVyIG9yIERv Y093bmVySWQgYXR0cmlidXRlDQoNCg0KOC40ICBUaGUgQXR0cmlidXRlIEdy b3VwIE1hcHBlZCB0byBQSkwNCg0KVGhlIGZvbGxvd2luZyBtYXBwaW5ncyBh cmUgcmVxdWlyZWQgaWYgdGhlIGxpc3RlZCBQSkwgYXR0cmlidXRlIG9yDQpj b21tYW5kIG9wdGlvbiBpcyBwcm92aWRlZC4NCg0KTUlCIGF0dHJpYnV0ZSAg ICAgICAgIHwgUEpMIGF0dHJpYnV0ZSBvciBjb21tYW5kIG9wdGlvbiAgfCBE YXRhIHR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLQ0Kc2VydmVy QXNzaWduZWRKb2JOYW1lIHwgRG9jTmFtZSBhdHRyaWJ1dGUgb3IgdGhlIGNv bW1hbmQgfCBPY3RldCBTdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICB8 ICBAUEpMIEpPQiBOYW1lID0gInN0cmluZyIgICAgICAgIHwgT2N0ZXQgU3Ry aW5nDQpzdWJtaXR0aW5nU2VydmVyTmFtZSAgfCBTcmNTZXJ2ZXJOYW1lIGF0 dHJpYnV0ZSAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iT3JpZ2luYXRp bmdIb3N0ICAgIHwgU3JjUG9ydCBhdHRyaWJ1dGUgICAgICAgICAgICAgICAg fCBPY3RldCBTdHJpbmcNCnF1ZXVlTmFtZVJlcXVlc3RlZCAgICB8IFNyY1Eg YXR0cmlidXRlICAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpm aWxlTmFtZSAgICAgICAgICAgICAgfCBKb2JGTmFtZSBhdHRyaWJ1dGUgICAg ICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iQ29tbWVudCAgICAgICAg ICAgIHwgSm9iRGVzYyBhdHRyaWJ1dGUgICAgICAgICAgICAgICAgfCBPY3Rl dCBTdHJpbmcNCmpvYlN1Ym1pc3Npb25UaW1lICAgICB8IFRpbWVTdWJtaXQg YXR0cmlidXRlICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KDQo5 LjAgIFBPU1RTQ1JJUFQNCg0KVGhlIFBvc3RTY3JpcHQgUERMIHBlcm1pdHMg Y29tbWVudCBmaWVsZHMgd2hpY2ggY2FuIGJlIHVzZWQgYnkNCmFwcGxpY2F0 aW9uIGRyaXZlcnMgdG8gaW5jbHVkZSBqb2IgaW5mb3JtYXRpb24uICBBbHRo b3VnaCB0aGVyZSBhcmUgbm8NCnJlc3RyaWN0aW9ucyBvciByZXF1aXJlbWVu dHMgYXMgdG8gd2hhdCBpbmZvcm1hdGlvbiBtYXkgYmUgaW5jbHVkZWQsDQpt YW55IGRyaXZlcnMgaW5jbHVkZSBqb2Igb3duZXIgYW5kL29yIGRvY3VtZW50 IG5hbWUuDQoNCg0KOS4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8g UG9zdFNjcmlwdA0KDQpUaGUgdXNlIG9mIGEgc3RhbmRhcmQgZm9ybWF0IGpv YiBzdWJtaXNzaW9uIGlkIGNvbW1lbnQgc3RyaW5nIHdpbGwgYWxsb3cNCmlu dGVyb3BlcmFiaWxpdHkgb2YgcHJpbnRlcnMgYW5kIGRyaXZlcnMgZnJvbSBt dWx0aXBsZSB2ZW5kb3JzLiAgVGhlDQpmb2xsb3dpbmcgY29tbWVudCBzdHJp bmcgZm9ybWF0IGlzIHJlY29tbWVuZGVkIGZvciB1c2Ugd2l0aCBQb3N0U2Ny aXB0DQpsZXZlbCAxIGFuZCBsZXZlbCAyIGRhdGEgc3RyZWFtcy4NCg0KICAg ICAlJUpNUEpvYlN1Ym1pc3Npb25JZDooaWQtc3RyaW5nKQ0KDQoNCg0KDQpC ZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAg ICAgICAgICAgICAgICAgICBbcGFnZSAxNl0NDA0KSU5URVJORVQtRFJBRlQg ICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAg IEZlYiA1LCAxOTk4DQoNCg0KDQoNCndoZXJlICJpZCBzdHJpbmciIGNhbiBi ZSBhbnkgam1Kb2JTdWJtaXNzaW9uSUQgZm9ybWF0IHJlc2VydmVkIGZvcg0K Y2xpZW50cy4NCg0KOS4yICBPdGhlciBNSUIgT2JqZWN0cyBhbmQgQXR0cmli dXRlcyBNYXBwZWQgdG8gUG9zdFNjcmlwdA0KDQpObyBPdGhlciBtYXBwaW5n cyBmcm9tIFBvc3RTY3JpcHQgY29tbWVudCBzdHJpbmdzIGFyZSByZWNvbW1l bmRlZCwgYnV0DQptYW55IEpvYiBNSUIgb2JqZWN0cyBhbmQgYXR0cmlidXRl cyBjYW4gYmUgZGVmaW5lZCB1c2luZyB2ZW5kb3IgdW5pcXVlDQpjb21tZW50 IHN0cmluZ3MuDQoNCg0KDQoxMC4wICBORVRXQVJFIFBTRVJWRVINCg0KVGhl IE5ldFdhcmUgUFNlcnZlciBqb2Igc3VibWlzc2lvbiBwcm90b2NvbCBpcyBp bXBsZW1lbnRlZCBpbiBhIGNsaWVudC0NCnNlcnZlci1wcmludGVyIHN5c3Rl bSBvbiB0aGUgc2VydmVyIHRvIHByaW50ZXIgbGluayBhcyBkZWZpbmVkIGlu DQpjb25maWd1cmF0aW9uIDMuDQoNCg0KMTAuMSAgam1Kb2JTdWJtaXNzaW9u SUQgTWFwcGVkIHRvIFBTZXJ2ZXINCg0KICBvY3RldCAxOiAgICdCJw0KDQoN CiAgb2N0ZXRzIDItNDA6ICBDb250YWlucyB0aGUgRGlyZWN0b3J5IFBhdGgg TmFtZSBvZiB0aGUgYWdlbnQgYXMNCiAgICAgICAgICAgICAgICByZWNvcmRl ZCBieSB0aGUgTm92ZWxsIEZpbGUgU2VydmVyIGluIHRoZSBxdWV1ZQ0KICAg ICAgICAgICAgICAgIGRpcmVjdG9yeS4gIElmIHRoZSBzdHJpbmcgaXMgbGVz cyB0aGFuIDQwIG9jdGV0cywgdGhlDQogICAgICAgICAgICAgICAgbGVmdC1t b3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5nIHNoYWxsIGFwcGVhciBpbiBv Y3RldA0KICAgICAgICAgICAgICAgIHBvc2l0aW9uIDIuICBPdGhlcndpc2Us IG9ubHkgdGhlIGxhc3QgMzkgYnl0ZXMgc2hhbGwgYmUNCiAgICAgICAgICAg ICAgICBpbmNsdWRlZC4gIEFueSB1bnVzZWQgcG9ydGlvbiBvZiB0aGlzIGZp ZWxkIHNoYWxsIGJlDQogICAgICAgICAgICAgICAgZmlsbGVkIHdpdGggc3Bh Y2VzLg0KDQogIG9jdGV0cyA0MS00ODogICcwMDBYWFhYWCcgIFRoZSBkZWNp bWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRpb24gb2YNCiAgICAgICAg ICAgICAgICAgdGhlIEpvYiBOdW1iZXIgYXMgcGVyIHRoZSBOZXRXYXJlIEZp bGUgU2VydmVyIFF1ZXVlDQogICAgICAgICAgICAgICAgIE1hbmFnZW1lbnQg U2VydmljZXMuDQoNCg0KMTAuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gUFNl cnZlcg0KDQpUaGUgam9iIGluZGV4IChqbUpvYkluZGV4KSBpcyBhc3NpZ25l ZCBieSB0aGUgU05NUCBqb2IgbW9uaXRvcmluZyBhZ2VudA0KYW5kIGlzIGlu ZGVwZW5kZW50IG9mIHRoZSBKb2IgTnVtYmVyIGFzc2lnbmVkIGJ5IHRoZSBO ZXRXYXJlIEZpbGUgU2VydmVyDQpRdWV1ZSBNYW5hZ2VtZW50IFNlcnZpY2Vz LiAgVGhpcyB3aWxsIGFsbG93IHRoZSBTTk1QIGFnZW50IHRvIHRyYWNrIGpv YnMNCnJlY2VpdmVkIGZyb20gbXVsdGlwbGUgc291cmNlcy4NCg0KDQoxMC4z ICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gUEpMDQoNCk1JQiBPYmpl Y3QgICAgICAgICAgICB8IFBTZXJ2ZXIgSm9iIGF0dHJpYnV0ZQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0Kam9iT3duZXIgICAgICAgICAgICAgIHwgQ2xp ZW50IElkIE51bWJlcg0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAg ICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAg W3BhZ2UgMTddDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNz aW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBGZWIgNSwgMTk5OA0KDQoN Cg0KDQoxMC40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQU2Vy dmVyDQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlm IHRoZSBsaXN0ZWQgUFNlcnZlciBwYXJhbWV0ZXIgaXMNCnByb3ZpZGVkIGlu IHRoZSBOb3ZlbGwgRmlsZSBTZXJ2ZXIgcXVldWUgZGlyZWN0b3J5Lg0KDQpN SUIgYXR0cmlidXRlICAgICAgICAgICAgICB8IFBTZXJ2ZXIgcGFyYW1ldGVy ICAgICAgICAgICB8IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tDQpzZXJ2ZXJBc3NpZ25lZEpvYk5hbWUgICAgICB8IEpvYiBGaWxl IE5hbWUgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0KcXVldWVOYW1l UmVxdWVzdGVkICAgICAgICAgfCBRdWV1ZSBJZCAgICAgICAgICAgICAgICAg ICAgfCBJbnRlZ2VyDQpwaHlzaWNhbERldmljZSAgICAgICAgICAgICB8IFNl cnZlciBJZCBOdW1iZXIgICAgICAgICAgICB8IEludGVnZXINCmpvYkNvbW1l bnQgICAgICAgICAgICAgICAgIHwgSm9iIERlc2NyaXB0aW9uICAgICAgICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JQcmlvcml0eSAgICAgICAgICAgICAg ICB8IChub3RlIDEpICAgICAgICAgICAgICAgICAgICB8IEludGVnZXINCmpv YlByb2Nlc3NBZnRlckRhdGVBbmRUaW1lIHwgVGFyZ2V0IEV4ZWN1dGlvbiBU aW1lICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JDb3BpZXNSZXF1ZXN0ZWQg ICAgICAgICB8IE51bWJlciBvZiBDb3BpZXMgICAgICAgICAgICB8IEludGVn ZXINCm1lZGl1bVJlcXVlc3RlZCAgICAgICAgICAgIHwgRm9ybSBOYW1lICAg ICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdWJtaXNzaW9u VG9TZXJ2ZXJUaW1lICB8IEpvYiBFbnRyeSBUaW1lICAgICAgICAgICAgICB8 IE9jdGV0IFN0cmluZw0KDQpOb3RlczoNCi0tLS0tLQ0KIDEuIFRoZSBqb2Ig cHJpb3JpdHkgaXMgZGV0ZXJtaW5lZCBieSB0aGUgcHJpb3JpdHkgYXNzaWdu ZWQgdG8gdGhlIHF1ZXVlDQogICAgdGhhdCBjb250YWlucyB0aGUgam9iLiAg RWFjaCBxdWV1ZSBjYW4gYmUgYXNzaWduZWQgYSB1bmlxdWUgcHJpb3JpdHkN CiAgICBhbmQgdGhlIHByaW9yaXR5IG9mIHRoZSBqb2IgaXMgaW5oZXJpdGVk IGZyb20gdGhlIHF1ZXVlLg0KDQoNCg0KMTEuMCAgTkVUV0FSRSBOUFJJTlRF UiBvciBSUFJJTlRFUg0KDQpUaGUgTmV0V2FyZSBOUHJpbnRlci9SUHJpbnRl ciBwcm90b2NvbCB3YXMgZGVzaWduZWQgdG8gdHJhbnNmZXIgcHJpbnQNCmRh dGEgZnJvbSBhIE5vdmVsbCBGaWxlIFNlcnZlciB0byBhIHByaW50ZXIgYXR0 YWNoZWQgZGlyZWN0bHkgdG8gYSBsb2NhbA0KcG9ydCAoZS5nLiBwYXJhbGxl bCBvciBzZXJpYWwpIG9uIGEgUEMuICBOUHJpbnRlci9SUHJpbnRlciBpcyBh bg0KZXh0cmVtZWx5IGxpZ2h0d2VpZ2h0IHByaW50aW5nIHByb3RvY29sLiAg Q29uc2VxdWVudGx5LCBubyBpbmZvcm1hdGlvbg0KcmVxdWlyZWQgYnkgdGhl IEpvYiBNb25pdG9yaW5nIE1JQiBpcyBwcm92aWRlZCBhbmQgYSBtZWFuaW5n ZnVsDQpqbUpvYlN1Ym1pc3Npb25JRCBjYW5ub3QgYmUgZ2VuZXJhdGVkLg0K DQpJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGFuIGFkZGl0aW9uYWwgam9iIHN1 Ym1pc3Npb24gbGF5ZXIsIHN1Y2ggYXMgUEpMDQpvciBhbm90aGVyIHZlbmRv ciBwcml2YXRlIHByb3RvY29sLCAgYmUgaW5jbHVkZWQgb24gdG9wIG9mDQpO UHJpbnRlci9SUHJpbnRlciB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBpbmZv cm1hdGlvbi4gIFRoZSBtYXBwaW5nDQpzaG91bGQgdGhlbiBiZSBwZXJmb3Jt ZWQgYWNjb3JkaW5nIHRvIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgdGhlIGhp Z2hlcg0KbGF5ZXIgc3VibWlzc2lvbiBwcm90b2NvbC4NCg0KDQoNCjEyLjAg IFNFUlZFUiBNRVNTQUdFIEJMT0NLIChTTUIpIFBST1RPQ09MDQoNClRoZSBT ZXJ2ZXIgTWVzc2FnZSBCbG9jayBwcm90b2NvbCBpcyB1c2VkIHdpdGggc2V2 ZXJhbCBQQyBOZXR3b3JrDQpvcGVyYXRpbmcgc3lzdGVtcywgc3VjaCBhcyBN aWNyb3NvZnQgV2luZG93cyBmb3IgV29ya2dyb3VwcywgSUJNIExBTg0KU2Vy dmVyLCBhbmQgQXJ0aXNvZnQgTGFudGFzdGljLiAgU01CIHN5c3RlbXMgc3Vw cG9ydGluZyB0aGUgSm9iDQpNb25pdG9yaW5nIE1JQiB3aWxsIGNvbmZvcm0g dG8gZWl0aGVyIGNvbmZpZ3VyYXRpb24gMSBvciAzLg0KDQoNCg0KDQoNCg0K DQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAg ICAgICAgICAgICAgICAgICAgICBbcGFnZSAxOF0NDA0KSU5URVJORVQtRFJB RlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAg ICAgIEZlYiA1LCAxOTk4DQoNCg0KDQoNCjEyLjEgIGptSm9iU3VibWlzc2lv bklEIE1hcHBlZCB0byBTTUINCg0KICBvY3RldCAxOiAgICdDJw0KDQogIG9j dGV0cyAyLTQwOiAgQ29udGFpbnMgYSBkZWNpbWFsIChBU0NJSSBjb2RlZCkg cmVwcmVzZW50YXRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAgMTYgYml0 IFNNQiBUcmVlIElkIGZpZWxkLCB3aGljaCB1bmlxdWVseSBpZGVudGlmaWVz IHRoZQ0KICAgICAgICAgICAgICAgIGNvbm5lY3Rpb24gdGhhdCBzdWJtaXR0 ZWQgdGhlIGpvYiB0byB0aGUgcHJpbnRlci4gIFRoZQ0KICAgICAgICAgICAg ICAgIG1vc3Qgc2lnbmlmaWNhbnQgZGlnaXQgb2YgdGhlIG51bWVyaWMgc3Ry aW5nIHNoYWxsIGJlDQogICAgICAgICAgICAgICAgcGxhY2VkIGluIG9jdGV0 IHBvc2l0aW9uIDIuICBBbGwgdW51c2VkIHBvcnRpb25zIG9mIHRoaXMNCiAg ICAgICAgICAgICAgICBmaWVsZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFj ZXMuICBUaGUgU01CIFRyZWUgSWQgaGFzDQogICAgICAgICAgICAgICAgYSBt YXhpbXVtIHZhbHVlIG9mIDY1LDUzNS4NCg0KICBvY3RldHMgNDEtNDg6ICBD b250YWlucyBhIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRhdGlv biBvZiB0aGUNCiAgICAgICAgICAgICAgICAgRmlsZSBIYW5kbGUgcmV0dXJu ZWQgZnJvbSB0aGUgcHJpbnRlciBhZ2VudCB0byB0aGUNCiAgICAgICAgICAg ICAgICAgY2xpZW50IGluIHJlc3BvbnNlIHRvIGEgQ3JlYXRlIFByaW50IEZp bGUgY29tbWFuZC4NCiAgICAgICAgICAgICAgICAgTGVhZGluZyB6ZXJvcyBz aGFsbCBiZSBpbnNlcnRlZCB0byBmaWxsIHRoZSBlbnRpcmUgOA0KICAgICAg ICAgICAgICAgICBvY3RldCBmaWVsZC4NCg0KDQoxMi4yICBqbUpvYkluZGV4 IE1hcHBlZCB0byBTTUINCg0KSXQgaXMgc3Ryb25nbHkgcmVjb21tZW5kZWQg dGhhdCB0aGUgRmlsZSBIYW5kbGUgcmV0dXJuZWQgZnJvbSB0aGUNCnByaW50 ZXIgYWdlbnQgYmUgaWRlbnRpY2FsIHRvIGptSm9iSW5kZXguICBJZiB0aGVz ZSBpdGVtcyBhcmUgaWRlbnRpY2FsLA0KdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dGhlIGNsaWVudCBhcHBsaWNhdGlvbiB0byBwZXJmb3JtIGEgc2VhcmNoIG9u DQpqbUpvYlN1Ym1pc3Npb25JRC4gIFRvIGJlIGNvbXBhdGlibGUgd2l0aCB0 aGUgMTYgYml0IGZpZWxkIGFsbG9jYXRlZCB0bw0KdGhpcyB2YWx1ZSBieSBT TUIsIHRoZSBtYXhpbXVtIGptSm9iSW5kZXggaXMgNjUsNTM1Lg0KDQoNCjEy LjMgIE90aGVyIE1JQiBvYmplY3RzIE1hcHBlZCB0byBTTUINCg0KTUlCIE9i amVjdCAgICAgIHwgU01CIFBhcmFtZXRlcg0KLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCmptSm9iT3duZXIgICAgICB8IFNNQiBVc2VyIElkIGZpZWxkIChub3Rl IDEpDQoNCk5vdGVzOg0KLS0tLS0tDQogMS4gQSBkZWNpbWFsIChBU0NJSSBj b2RlZCkgcmVwcmVzZW50YXRpb24gb2YgdGhlIFNNQiBVc2VyIElkIG51bWVy aWMNCiAgICBzaGFsbCBiZSBwcmVzZW50ZWQgYXMgam1Kb2JPd25lci4NCg0K DQoNCjEzLjAgIFRSQU5TUE9SVCBJTkRFUEVOREVOVCBQUklOVEVSL1NZU1RF TSBJTlRFUkZBQ0UgKFRJUC9TSSkNCg0KVGhlIFRJUC9TSSBwcm90b2NvbCwg YWx0aG91Z2ggY3VycmVudGx5IHNwZWNpZmllZCBhcyBhIHBhcnQgb2YgdGhl IElFRUUNCjEyODQgcGFyYWxsZWwgcG9ydCBzdGFuZGFyZHMgW1RJUC9TSV0s IHdhcyBvcmlnaW5hbGx5IGRldmVsb3BlZCBhcyBhDQpuZXR3b3JrIHByb3Rv Y29sLiAgVElQL1NJIHRodXMgaGFzIHRoZSBwb3RlbnRpYWwgb2YgYmVpbmcg aW50ZWdyYXRlZA0KaW50byBhbnkgbmV0d29yayBvciBub24tbmV0d29yayBj b25maWd1cmF0aW9uLg0KDQoxMy4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBw ZWQgdG8gVElQL1NJDQoNCiAgb2N0ZXQgMTogICAnRCcNCg0KDQoNCg0KQmVy Z21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAg ICAgICAgICAgICAgICAgW3BhZ2UgMTldDQwNCklOVEVSTkVULURSQUZUICAg ICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgICBG ZWIgNSwgMTk5OA0KDQoNCg0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMg dGhlIEpvYiBOYW1lIGZyb20gdGhlIEpvYiBDb250cm9sLVN0YXJ0IEpvYg0K ICAgICAgICAgICAgICAgIChKQy1TSikgY29tbWFuZC4gIElmIHRoZSBKb2Ig TmFtZSBwb3J0aW9uIGlzIGxlc3MgdGhhbg0KICAgICAgICAgICAgICAgIDQw IG9jdGV0cywgdGhlIGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmlu ZyBzaGFsbA0KICAgICAgICAgICAgICAgIGFwcGVhciBpbiBvY3RldCBwb3Np dGlvbiAyLiAgQW55IHVudXNlZCBwb3J0aW9uIG9mIHRoaXMNCiAgICAgICAg ICAgICAgICBmaWVsZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuICBP dGhlcndpc2UsIG9ubHkgdGhlDQogICAgICAgICAgICAgICAgbGFzdCAzOSBi eXRlcyBzaGFsbCBiZSBpbmNsdWRlZC4NCg0KDQogIG9jdGV0cyA0MS00ODog IENvbnRhaW5zIGEgZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0 aW9uIG9mIHRoZQ0KICAgICAgICAgICAgICAgICBqbUpvYkluZGV4IGFzc2ln bmVkIGJ5IHRoZSBhZ2VudC4gIExlYWRpbmcgemVyb3Mgc2hhbGwNCiAgICAg ICAgICAgICAgICAgYmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDgg b2N0ZXQgZmllbGQuDQoNCjEzLjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFRJ UC9TSQ0KDQpqbUpvYkluZGV4IGlzIHJldHVybmVkIHRvIHRoZSBjbGllbnQg YXMgdGhlIFByaW50ZXIgQXNzaWduZWQgSm9iIElkIGluIGENCkpvYiBDb250 cm9sLVN0YXJ0IEpvYiAoSkMtU0opIHJlc3BvbnNlIHBhY2tldC4gIFRvIGJl IGNvbXBhdGlibGUgd2l0aA0KdGhlIDE2IGJpdCBmaWVsZCBhbGxvY2F0ZWQg dG8gdGhpcyB2YWx1ZSBieSBUSVAvU0ksIHRoZSBtYXhpbXVtDQpqbUpvYklu ZGV4IGlzIDY1LDUzNS4NCg0KDQoxMy4zICBPdGhlciBNSUIgT2JqZWN0cyBN YXBwZWQgdG8gVElQL1NJDQoNCk1JQiBPYmplY3QgICAgICAgICAgICAgfCBU SVAvU0kgUGFyYW1ldGVyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CmptSm9iT3duZXIgICAgICAgICAgICAgfCBVc2VyIHN0cmluZw0KDQoNCjEz LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIFRJUC9TSQ0KDQpN SUIgYXR0cmlidXRlICAgICAgICAgfCBUSVAvU0kgaW5mb3JtYXRpb24gICAg ICAgICAgICAgIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLQ0Kam9iTmFtZSAgICAgICAgICAgICAgIHwgSm9iIE5hbWUgc3RyaW5n ICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iQ29tbWVudCAg ICAgICAgICAgIHwgQWRkaXRpb25hbCBJbmZvcm1hdGlvbiBzdHJpbmcgICB8 IE9jdGV0IFN0cmluZw0KDQoNCg0KMTQuMCAgUkVGRVJFTkNFUw0KDQpbRFBB XSAgSVNPL0lFQyAxMDE3NS0xOjE5OTYoRSksICJJbmZvcm1hdGlvbiB0ZWNo bm9sb2d5IC0gVGV4dCBhbmQNCm9mZmljZSBzeXN0ZW1zIC0gRG9jdW1lbnQg UHJpbnRpbmcgQXBwbGljYXRpb24gKERQQSkgLSBQYXJ0IDE6IEFic3RyYWN0 DQpzZXJ2aWNlIGRlZmluaXRpb24gYW5kIHByb2NlZHVyZXMiLCBKVEMxL1ND MTguDQoNCltJUFBdICBUaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wg UkZDIFhYWFgsIE1vZGVsIFJGQyBYWFhYDQoNCltJU08tODgyNF0gIElTTy9J RUMgODgyNDoxOTkwLCAiSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtIE9wZW4g U3lzdGVtcw0KSW50ZXJjb25uZWN0aW9uIC0gU3BlY2lmaWNhdGlvbiBvZiBB YnN0cmFjdCBTeW50YXggTm90YXRpb24gKEFTTi4xKSIuDQoNCltKb2JNSUJd ICBUaGUgSm9iIE1vbml0b3JpbmcgTUlCLCB3b3JrIGluIHByb2dyZXNzLCA8 ZHJhZnQtaWV0Zi0NCnByaW50bWliLWpvYi1tb25pdG9yaW5nLTA3LnR4dD4s IHRvIGJlIHB1Ymxpc2hlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KYXMg YSBQcmludGVyIFdvcmtpbmcgR3JvdXAgKFBXRykgc3RhbmRhcmQuDQoNCg0K DQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9u YWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMjBdDQwNCklOVEVSTkVU LURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcg ICAgICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQpbTFBEXSAgTGluZSBQcmlu dGVyIERhZW1vbiBQcm90b2NvbCwgUkZDIDExNzksIElFVEYgaW5mb3JtYXRp b25hbA0KZG9jdW1lbnQuDQoNCltQSkxdICBQcmludGVyIEpvYiBMYW5ndWFn ZSBUZWNobmljYWwgUmVmZXJlbmNlIE1hbnVhbCwgSGV3bGV0dC1QYWNrYXJk DQpwYXJ0IG51bWJlciA1MDIxLTAzMjguDQoNCltQcnRNSUJdICBUaGUgUHJp bnRlciBNSUIsIFJGQyAxNzU5LCBJRVRGIHN0YW5kYXJkcyB0cmFjayBkb2N1 bWVudC4NCg0KW1RJUC9TSV0gIElFRUUgU3RhbmRhcmQgMTI4NC4xLCBUcmFu c3BvcnQgSW5kZXBlbmRlbnQgUHJpbnRlci9TeXN0ZW0NCkludGVyZmFjZS4N Cg0KDQoNCjE1LjAgIEFVVEhPUlMNCg0KVGhpcyBkb2N1bWVudCB3YXMgY3Jl YXRlZCB3aXRoIHNpZ25pZmljYW50IGNvbnRyaWJ1dGlvbnMgZnJvbSB0aGUN CmZvbGxvd2luZyBpbmRpdmlkdWFscy4NCg0KICAgIFJvbiBCZXJnbWFuIChF ZGl0b3IpDQogICAgRGF0YXByb2R1Y3RzIENvcnAuDQogICAgMTc1NyBUYXBv IENhbnlvbiBSb2FkDQogICAgU2ltaSBWYWxsZXksIENBIDkzMDYzLTMzOTQN Cg0KICAgIFBob25lOiA4MDUtNTc4LTQ0MjENCiAgICBGYXg6ICA4MDUtNTc4 LTQwMDENCiAgICBFbWFpbDogcmJlcmdtYW5AZHBjLmNvbQ0KDQoNCiAgICBU b20gSGFzdGluZ3MNCiAgICBYZXJveCBDb3Jwb3JhdGlvbiwgRVNBRS0yMzEN CiAgICA3MDEgUy4gQXZpYXRpb24gQmx2ZC4NCiAgICBFbCBTZWd1bmRvLCBD QSAgIDkwMjQ1DQoNCiAgICBQaG9uZTogMzEwLTMzMy02NDEzDQogICAgRmF4 OiAgIDMxMC0zMzMtNTUxNA0KICAgIEVNYWlsOiBoYXN0aW5nc0BjcDEwLmVz Lnhlcm94LmNvbQ0KDQoNCiAgICBTY290dCBBLiBJc2FhY3Nvbg0KICAgIE5v dmVsbCwgSW5jLg0KICAgIDEyMiBFIDE3MDAgUw0KICAgIFByb3ZvLCBVVCAg IDg0NjA2DQoNCiAgICBQaG9uZTogODAxLTg2MS03MzY2DQogICAgRmF4OiAg IDgwMS04NjEtNDAyNQ0KICAgIEVNYWlsOiBzY290dF9pc2FhY3NvbkBub3Zl bGwuY29tDQoNCg0KICAgIEhhcnJ5IExld2lzDQogICAgSUJNIENvcnBvcmF0 aW9uDQogICAgNjMwMCBEaWFnb25hbCBId3kNCiAgICBCb3VsZGVyLCBDTyA4 MDMwMQ0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMjFdDQwNCklO VEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1h cHBpbmcgICAgICAgICBGZWIgNSwgMTk5OA0KDQoNCg0KDQoNCiAgICBQaG9u ZTogKDMwMykgOTI0LTUzMzcNCiAgICBGYXg6ICAgKDMwMykgOTI0LTQ2NjIN CiAgICBFbWFpbDogaGFycnlsQHVzLmlibS5jb20NCg0KDQogICAgQm9iIFBl bnRlY29zdA0KICAgIEhld2xldHQtUGFja2FyZCBDb3Jwb3JhdGlvbg0KICAg IDExMzExIENoaW5kZW4gQm91bGV2YXJkDQogICAgQm9pc2UsIElEIDgzNzE0 DQoNCiAgICBQaG9uZTogKDIwOCkgMzk2LTMzMTINCiAgICBGYXg6ICAgKDIw OCkgMzk2LTQxMjINCiAgICBFbWFpbDogYnBlbnRlY29AYm9pLmhwLmNvbQ0K DQoNCiAgICBTZW5kIGNvbW1lbnRzIHRvIHRoZSBwcmludG1pYiBXRyB1c2lu ZyB0aGUgSm9iIE1vbml0b3JpbmcgUHJvamVjdA0KICAgIChKTVApIE1haWxp bmcgTGlzdDogIGptcEBwd2cub3JnDQoNCiAgICBGb3IgZnVydGhlciBpbmZv cm1hdGlvbiwgYWNjZXNzIHRoZSBQV0cgd2ViIHBhZ2UgdW5kZXIgIkpNUCI6 DQogICAgaHR0cDovL3d3dy5wd2cub3JnLw0KDQoNCk90aGVyIFBhcnRpY2lw YW50czoNCg0KICAgIENodWNrIEFkYW1zIC0gVGVrdHJvbml4DQogICAgS2Vp dGggQ2FydGVyIC0gSUJNIENvcnBvcmF0aW9uDQogICAgQW5nZWxvIENhcnVz byAtIFhlcm94DQogICAgSmVmZiBDb3BlbGFuZCAtIFFNUw0KICAgIEFuZHkg RGF2aWRzb24gLSBUZWt0cm9uaXgNCiAgICBNYWJyeSBEb3ppZXIgLSBRTVMN CiAgICBMZWUgRmVycmVsIC0gQ2Fub24NCiAgICBEYXZpZCBLZWxsZXJtYW4g LSBOb3J0aGxha2UgU29mdHdhcmUNCiAgICBSaWNrIExhbmRhdSAtIERpZ2l0 YWwNCiAgICBKYXkgTWFydGluIC0gVW5kZXJzY29yZQ0KICAgIElyYSBNY0Rv bmFsZCAtIFhlcm94DQogICAgU3R1YXJ0IFJvd2xleSAtIEt5b2NlcmENCiAg ICBCb2IgU2V0dGVyYm8gLSBBZG9iZQ0KICAgIEdhaWwgU29uZ2VyIC0gRUZJ DQogICAgTWlrZSBUaW1wZXJtYW4gLSBMZXhtYXJrDQogICAgV2lsbGlhbSBX YWduZXIgLSBEUEkvT3NpY29tDQogICAgQ2hyaXMgV2VsbGVucyAtIEludGVy d29ya2luZyBMYWJzDQogICAgUm9iIFdoaXR0bGUgLSBOb3ZlbGwNCiAgICBE b24gV3JpZ2h0IC0gTGV4bWFyaw0KICAgIExsb3lkIFlvdW5nIC0gTGV4bWFy aw0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAg ICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFn ZSAyMl0NDA== --3557085-27310-886696028=:55-- From hastings at cp10.es.xerox.com Fri Feb 6 22:10:36 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:14 2009 Subject: JMP> I've posted and forwarded Message-ID: <3.0.1.32.19980206191036.00b23ba0@garfield> The first PWG standard is now forwarded as in Internet-Draft: The PWG Job Monitoring MIB V1.0 Ron and I compiled the file with an additional number of SNMP compilers and fixed formatting problems. The Job Monitoring MIB now compiles with: SNMCng compiler (we had to comment out the long attributes TC in the .txt file) Epilogue V6.0 MOSY 7.1 HP OpenView Network Node Manager, release B.05.01 (no changes needed) NetPlus (needed spaces before parens, also it doesn't understand the enterprises arc, but we didn't fix that) I've posted the files in: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/mibvaria.dot The .txt file is the same as the internet-draft. The jmp-mib.pdf has line numbers and should be used for reference. It has the same pagination as the .txt file. Ron will request that it and his mapping document be forwarded to the IESG to be distributed as a pair of informational RFCs next week. Tom >X-Sender: hastings@garfield >Date: Fri, 06 Feb 1998 18:54:53 -0800 >To: internet-drafts@ietf.org >From: Tom Hastings >Subject: >Cc: Chris Wellens , Ron Bergman , > Tom Hastings , > Lloyd Young , don@lexmark.com > >Here is the next Internet-Draft for a Job Monitoring MIB: > > >I've included the file as an attachment in order to preserve the >FORM FEEDs. If you have any trouble with the attachment, please >reply and I'll resend in the body of the message. > > Title : Job Monitoring MIB > Author(s) : R. Bergman, T. Hastings, S. Isaacson, H. Lewis > Filename : draft-ietf-printmib-job-monitor-07.txt > Pages : 110 > Date : 02/03/1998 > >The Abstract is: > >This document has been developed and approved by the Printer Working Group >(PWG) as a PWG standard. It is intended to be distributed as an >Informational RFC. This document provides a printer industry standard SNMP >MIB for (1) monitoring the status and progress of print jobs (2) obtaining >resource requirements before a job is processed, (3) monitoring resource >consumption while a job is being processed and (4) collecting resource >accounting data after the completion of a job. This MIB is intended to be >implemented (1) in a printer or (2) in a server that supports one or more >printers. Use of the object set is not limited to printing. However, >support for services other than printing is outside the scope of this Job >Monitoring MIB. Future extensions to this MIB may include, but are not >limited to, fax machines and scanners. > >Thanks, >Tom Hastings >For the Printer Working Group (PWG) > > From carterk at us.ibm.com Mon Feb 9 09:27:25 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:14 2009 Subject: JMP> A friendly reminder to "ping" for the PWG meeting in Austin Message-ID: <3.0.1.32.19980206191036.00b23ba0@garfield> Here's a friendly reminder. Please send me a "ping" by 3:00PM CST on Tuesday, 2/10 for the PWG meeting in Austin, Texas on 3/2-6. Attached is my original note with the information and request. To date, only 10 people have sent me a "ping". Thanks, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-09-98 08:23 AM --------------------------- Keith Carter 02-02-98 11:29 AM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, I'll be the host for the PWG meeting in Austin, Texas on 3/2-6. Here's the scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10. HOTEL INFORMATION Hyatt Regency Austin (located on Town Lake in downtown Austin). Phone: 512-477-1234 $101 per night (single occupancy). Meeting room charge will be based on meeting attendance per day (see PING INFORMATION) Cab fare from airport is $12-14. Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10 blocks for the athletically inclined). Restaurants within 1 block of the hotel include: Threadgills (famous for their home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill). The Hyatt also has a very good restaurant. Chuy's (Tex Mex and cool t-shirts) and other restaurants are within a short drive of the hotel. For you olympians, there is a public jogging trail that goes by the hotel and around the lake. PWG MEETING AGENDA Here is the agenda proposed by Don Wright: Monday (3/2), Tuesday (3/3): -- 1394 Printing Wednesday (3/4) AM: -- PWG overview session -- Discussion on NC Printing Wednesday (3/4) PM: -- IPP Thursday (3/5): -- IPP Friday (3/6): -- Finisher -- Job MIB Traps Please address any questions on the PWG agenda to Don Wright. Please address any questions on a working group agenda to the working group chair. PING INFORMATION Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following information: 1) What meeting dates will you attend? 2) Will you stay at the Hyatt hotel? 3) If you are staying at the Hyatt, what are your arrival and departure dates? On 2/11, I'll provide the information to the hotel, distribute a list of attendees to the PWG distribution lists, and provide you with the meeting room costs per day. On 2/12 you may start making your reservations at the Hyatt hotel under the name "Printer Working Group". Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From carterk at us.ibm.com Mon Feb 9 14:06:24 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:14 2009 Subject: JMP> Getting the $101 rate at the Hyatt hotel for the PWG meeting Message-ID: <3.0.1.32.19980206191036.00b23ba0@garfield> Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From mark at mtesoft.com Mon Feb 9 14:43:14 1998 From: mark at mtesoft.com (Mark T. Edmead) Date: Wed May 6 14:00:14 2009 Subject: JMP> RE: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Message-ID: <3.0.1.32.19980206191036.00b23ba0@garfield> Keith: Yes, I already made reservervations for myself and Larry Stein at the higher rate. If you could inform Hyatt when you call them that would be great. Like I said earlier, I will be out of the country for a while, this is why I made the reservations so early. Thanks! Mark -----Original Message----- From: Keith Carter [SMTP:carterk@us.ibm.com] Sent: Monday, February 09, 1998 11:06 AM To: p1394@pwg.org; pwg@pwg.org; fin@pwg.org; jmp@pwg.org; ipp@pwg.org Subject: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting Per my original note, you may make reservations under "PWG" at the Hyatt hotel for the rate of $101/night starting on Thursday 2/12. The Hyatt hotel won't lock in the rate until I give them a list of people with arrival and departure dates. Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I can send this information to the Hyatt on 2/11. The hotel will then open reservations under "PWG" at $101/night on 2/12. Anyone who makes reservations at a higher rate before 2/12 should notify me because the Hyatt will lower their rate to $101 if I inform them to do so on 2/11. The Hyatt hotel is holding 25 rooms per night for the PWG through 2/11 but they require names to reserve these rooms so please ping soon! To date, I have received 14 pings. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From Internet-Drafts at ns.ietf.org Tue Feb 10 18:06:19 1998 From: Internet-Drafts at ns.ietf.org (Internet-Drafts@ns.ietf.org) Date: Wed May 6 14:00:14 2009 Subject: JMP> I-D ACTION:draft-ietf-printmib-job-monitor-07.txt Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Title : Job Monitoring MIB - V1 Author(s) : T. Hasting, H. Lewis, S. Isaacson, R. Bergman Filename : draft-ietf-printmib-job-monitor-07.txt Pages : 111 Date : 09-Feb-98 This document has been developed and approved by the Printer Working Group (PWG) as a PWG standard. It is intended to be distributed as an Informational RFC. This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-monitor-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-printmib-job-monitor-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-monitor-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From rbergma at dpc.com Wed Feb 11 11:25:51 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> Internet-Draft for Job Submission Protocol Mapping Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> DQpUaGlzIGlzIGEgc3VibWlzc2lvbiBvZiB0aGUgbGF0ZXN0IEludGVybmV0 LURyYWZ0IG9mIGEgY29tcGFuaW9uIGRvY3VtZW50DQp0byB0aGUgSm9iIE1v bml0b3JpbmcgTUlCIHRoYXQgcHJvdmlkZXMgYSBtYXBwaW5nIG9mIEpvYiBT dWJtaXNzaW9uDQpQcm90b2NvbHMgdG8gdGhlIEpvYiBNSUI6DQoNCg0KICAg ICAgIFRpdGxlICAgICA6IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBp bmcgUmVjb21tZW5kYXRpb25zIGZvcg0KICAgICAgICAgICAgICAgICAgIHRo ZSBKb2IgTW9uaXRvcmluZyBNSUIgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgQXV0aG9yKHMpIDogUi4gQmVyZ21hbg0KICAgICAgIEZpbGVu YW1lICA6IGRyYWZ0LWlldGYtcHJpbnRtaWItam9iLXByb3RvbWFwLTAzLnR4 dA0KICAgICAgIFBhZ2VzICAgICA6IDIzDQogICAgICAgRGF0ZSAgICAgIDog RmVicnVhcnkgMTAsIDE5OTgNCg0KDQpUaGUgQWJzdHJhY3QgaXM6DQoNCiAg ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBkZWZpbmVzIHRoZSByZWNvbW1lbmRl ZCBtYXBwaW5nIGZvciBtYW55DQogICAgIGN1cnJlbnRseSBwb3B1bGFyIEpv YiBzdWJtaXNzaW9uIHByb3RvY29scyB0byBvYmplY3RzIGFuZA0KICAgICBh dHRyaWJ1dGVzIHRoZSBKb2IgTW9uaXRvcmluZyBNSUIuDQoNCg0KCVRoYW5r IHlvdSwNCglSb24gQmVyZ21hbg0KCUZvciB0aGUgcHJpbnRtaWIgV0cNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KDQoNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIEJlcmdtYW4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIERhdGFwcm9kdWN0cyBDb3JwLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDEw LCAxOTk4DQoNCg0KICAgICAgICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3Rv Y29sIE1hcHBpbmcgUmVjb21tZW5kYXRpb25zDQogICAgICAgICAgICAgICAg ICAgICAgIGZvciB0aGUgSm9iIE1vbml0b3JpbmcgTUlCDQoNCiAgICAgICAg ICAgICAgIDxkcmFmdC1pZXRmLXByaW50bWliLWpvYi1wcm90b21hcC0wMy50 eHQ+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDEwLCAxOTk4DQoNCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgICAg VGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdC4gIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZw0KICAgICBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJl YXMsDQogICAgIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0KDQogICAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1h eGltdW0gb2Ygc2l4DQogICAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXINCiAgICAgZG9jdW1l bnRzIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzDQogICAgIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbg0KICAgICBw cm9ncmVzcyIuDQoNCiAgICAgVG8gbGVhcm4gdGhlIGN1cnJlbnQgc3RhdHVz IG9mIGFueSBJbnRlcm5ldC1EcmFmdCwgcGxlYXNlIGNoZWNrIHRoZQ0KICAg ICAiMWlkLWFic3RyYWN0cy50eHQiIGxpc3RpbmcgY29udGFpbmVkIGluIHRo ZSBJbnRlcm5ldC1EcmFmdHMgU2hhZG93DQogICAgIERpcmVjdG9yaWVzIG9u IGZ0cC5pcy5jby56YSAoQWZyaWNhKSwgbmljLm5vcmR1Lm5ldCAoRXVyb3Bl KSwNCiAgICAgbXVubmFyaS5vei5hdSAoUGFjaWZpYyBSaW0pLCBkcy5pbnRl cm5pYy5uZXQgKFVTIEVhc3QgQ29hc3QpLCBvcg0KICAgICBmdHAuaXNpLmVk dSAoVVMgV2VzdCBDb2FzdCkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQWJzdHJhY3QNCg0KICAgICBUaGlzIEludGVybmV0LURyYWZ0 IGRlZmluZXMgdGhlIHJlY29tbWVuZGVkIG1hcHBpbmcgZm9yIG1hbnkNCiAg ICAgY3VycmVudGx5IHBvcHVsYXIgSm9iIHN1Ym1pc3Npb24gcHJvdG9jb2xz IHRvIG9iamVjdHMgYW5kDQogICAgIGF0dHJpYnV0ZXMgaW4gdGhlIEpvYiBN b25pdG9yaW5nIE1JQi4NCg0KDQoNCg0KDQoNClRBQkxFIE9GIENPTlRFTlRT DQoNCjEuMCAgSU5UUk9EVUNUSU9OLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KMi4wICBMSU5FIFBS SU5URVIgREFFTU9OIChMUFIvTFBEKSBQUk9UT0NPTC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi40DQoyLjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBl ZCB0byBMUFIvTFBELi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQN CjIuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gTFBSL0xQRC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0KMi4zICBPdGhlciBNSUIg T2JqZWN0cyBNYXBwZWQgdG8gTFBSL0xQRC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi41DQoyLjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVk IHRvIExQRC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCg0K DQoNCkJlcmdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAxXQ0MDQpJTlRFUk5FVC1E UkFGVCAgICAgICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBwaW5nICAg ICAgICBGZWIgMTAsIDE5OTgNCg0KDQoNCg0KMy4wICBBUFBMRVRBTEsgUFJP VE9DT0wuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi42DQozLjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBB cHBsZVRhbGsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCjMuMiAg T3RoZXIgQXBwbGVUYWxrIE1hcHBpbmdzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KNC4wICBJTlRFUk5FVCBQUklOVElO RyBQUk9UT0NPTCAoSVBQKS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi42DQo0LjEgIGptSm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBJUFAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcNCjQuMiAgam1K b2JJbmRleCBNYXBwZWQgdG8gSVBQLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNw0KNC4zICBPdGhlciBNSUIgT2JqZWN0cyBN YXBwZWQgdG8gSVBQLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li43DQo0LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIElQUC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjgNCjUuMCAgSU5URUxM SUdFTlQgUFJJTlRFUiBEQVRBIFNUUkVBTSAoSVBEUykuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uOQ0KNS4xICBqbUpvYlN1Ym1pc3Npb25JZCBNYXBw ZWQgdG8gSVBEUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45 DQo1LjIgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIElQRFMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCjYuMCAgRE9DVU1FTlQg UFJJTlRJTkcgQVBQTElDQVRJT04gKERQQSkuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4xMA0KNi4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQg dG8gRFBBLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExDQo2 LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIERQQS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTENCjYuMyAgT3RoZXIgTUlCIE9i amVjdHMgTWFwcGVkIHRvIERQQS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xMQ0KNi40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0 byBEUEEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyDQo3LjAg IE5PVkVMTCBESVNUUklCVVRFRCBQUklOVCBTRVJWSUNFIChORFBTKS4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCjcuMSAgam1Kb2JTdWJtaXNzaW9u SUQgTWFwcGVkIHRvIE5EUFMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xMw0KNy4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBORFBTLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzDQo3LjMgIE90 aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0byBORFBTLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTMNCjcuNCAgVGhlIEF0dHJpYnV0ZSBHcm91 cCBNYXBwZWQgdG8gTkRQUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xNA0KOC4wICBQUklOVEVSIEpPQiBMQU5HVUFHRSAoUEpMKS4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1DQo4LjEgIGptSm9i U3VibWlzc2lvbklEIE1hcHBlZCB0byBQSkwuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTYNCjguMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8g UEpMLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x Ng0KOC4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gUEpMLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2DQo4LjQgIFRoZSBBdHRy aWJ1dGUgR3JvdXAgTWFwcGVkIHRvIFBKTC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTYNCjkuMCAgUE9TVFNDUklQVC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNw0K OS4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQgdG8gUG9zdFNjcmlwdC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3DQo5LjIgIE90aGVyIE1JQiBP YmplY3RzIGFuZCBBdHRyaWJ1dGVzIE1hcHBlZCB0byBQb3N0U2NyaXB0Li4u Li4uLi4uLi4uMTcNCjEwLjAgIE5FVFdBUkUgUFNFUlZFUi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNw0KMTAu MSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFBTZXJ2ZXIuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjE3DQoxMC4yICBqbUpvYkluZGV4IE1h cHBlZCB0byBQU2VydmVyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTgNCjEwLjMgIE90aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0byBQ SkwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOA0KMTAuNCAg VGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8gUFNlcnZlci4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjE4DQoxMS4wICBORVRXQVJFIE5QUklOVEVS IG9yIFJQUklOVEVSLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTkNCjEyLjAgIFNFUlZFUiBNRVNTQUdFIEJMT0NLIChTTUIpIFBST1RP Q09MLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOQ0KMTIuMSAgam1K b2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFNNQi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjE5DQoxMi4yICBqbUpvYkluZGV4IE1hcHBlZCB0 byBTTUIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTkNCjEyLjMgIE90aGVyIE1JQiBvYmplY3RzIE1hcHBlZCB0byBTTUIuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0KMTMuMCAgVFJBTlNQ T1JUIElOREVQRU5ERU5UIFBSSU5URVIvU1lTVEVNIElOVEVSRkFDRSAoVElQ L1NJKS4uLi4uLi4uLjIwDQoxMy4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBw ZWQgdG8gVElQL1NJLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjAN CjEzLjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFRJUC9TSS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMA0KMTMuMyAgT3RoZXIgTUlC IE9iamVjdHMgTWFwcGVkIHRvIFRJUC9TSS4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjIxDQoxMy40ICBUaGUgQXR0cmlidXRlIEdyb3VwIE1hcHBl ZCB0byBUSVAvU0kuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjENCjE0 LjAgIFJFRkVSRU5DRVMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMQ0KMTUuMCAgQVVUSE9SUy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjIyDQoNCg0KDQoNCg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAg ICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAg ICBbcGFnZSAyXQ0MDQpJTlRFUk5FVC1EUkFGVCAgICAgICBKb2IgU3VibWlz c2lvbiBQcm90b2NvbCBNYXBwaW5nICAgICAgICBGZWIgMTAsIDE5OTgNCg0K DQoNCg0KDQoxLjAgIElOVFJPRFVDVElPTg0KDQpUaGUgSm9iIE1vbml0b3Jp bmcgTUlCIFtKb2JNSUJdIGlzIGludGVuZGVkIHRvIGJlIGltcGxlbWVudGVk IGluIGENCmRldmljZSBvciBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBhbnkgam9i IHN1Ym1pc3Npb24gcHJvdG9jb2wuICBIb3dldmVyLA0KdGhlIGluZm9ybWF0 aW9uIGF2YWlsYWJsZSBhbmQgdGhlIG1ldGhvZCBvZiBwcmVzZW50YXRpb24g dmFyaWVzDQpzaWduaWZpY2FudGx5IGJ5IGpvYiBzdWJtaXNzaW9uIHByb3Rv Y29sLiAgQSBjb21tb24gbWV0aG9kIG9mIG1hcHBpbmcNCmpvYiBzdWJtaXNz aW9uIGluZm9ybWF0aW9uIHRvIHRoZSBKb2IgTW9uaXRvcmluZyBNSUIgaXMg ZXNzZW50aWFsIGZvcg0KaW50ZXJvcGVyYWJpbGl0eSBvZiBKb2IgTUlCIGFn ZW50cyBhbmQgbW9uaXRvcmluZyBhcHBsaWNhdGlvbnMuICBUaGlzDQpkb2N1 bWVudCBkZWZpbmVzIHJlY29tbWVuZGVkIG1hcHBpbmdzIGZvciBtb3N0IHBv cHVsYXIgam9iIHN1Ym1pc3Npb24NCnByb3RvY29scyB0byBpbnN1cmUgdGhp cyBjb21wYXRpYmlsaXR5Lg0KDQpBbGwgbWFwcGluZ3MgYXJlIHVuaWRpcmVj dGlvbmFsIGZyb20gdGhlIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sIHRvIHRo ZQ0KTUlCLiAgSXQgaXMgYXNzdW1lZCB0aGF0IHN1cHBvcnQgb2YgdGhlIGpv YiBzdWJtaXNzaW9uIHByb3RvY29sIGluIHRoZQ0KcHJpbnRlciBpbXBsaWVz IHRoYXQgdGhlIHJldmVyc2UgaW5mb3JtYXRpb24gZmxvdyBpcyBwcmVzZW50 bHkgZGVmaW5lZA0KYW5kIGRvZXMgbm90IHJlcXVpcmUgaW50ZXJhY3Rpb24g ZnJvbSB0aGUgTUlCLiAgVGhpcyBtYXBwaW5nIGlzIG5vdA0KZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IGFzIGl0IHNob3VsZCBiZSBvYnZpb3VzLg0KDQpU aGlzIGRvY3VtZW50IHJlZmVycyB0byBzeXN0ZW0gY29uZmlndXJhdGlvbnMg dGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUNCkpvYiBNb25pdG9yaW5nIE1JQiBb Sm9iTUlCXS4gIEZvciB0aG9zZSByZWFkZXJzIHRoYXQgYXJlIGZhbWlsaWFy IHdpdGgNCnRoZSBjb25maWd1cmF0aW9uIGRlc2NyaXB0aW9ucywgYSBzaG9y dCBzdW1tYXJ5IGFwcGVhcnMgaGVyZS4gIFBsZWFzZQ0Kc2VlIHRoZSBKb2Ig TUlCIGRvY3VtZW50IGZvciBmdXJ0aGVyIGRldGFpbHMuDQoNCiAgIENvbmZp Z3VyYXRpb24gMTogIFRoaXMgaXMgYSBzaW1wbGUgcGVlci10by1wZWVyIHN5 c3RlbSB3aGljaCBjb250YWlucw0KICAgICAgIG9ubHkgYSBjbGllbnQgYW5k IGEgcHJpbnRlci4gIFRoZSBKb2IgTUlCIGFnZW50IGlzIHJlc2lkZW50IGlu DQogICAgICAgdGhlIHByaW50ZXIuDQoNCiAgIENvbmZpZ3VyYXRpb24gMjog IFRoaXMgc3lzdGVtIGNvbnRhaW5zIGEgY2xpZW50LCBzZXJ2ZXIsIGFuZCBh DQogICAgICAgcHJpbnRlci4gIFRoZSBKaWIgTUlCIGFnZW50IGlzIHJlc2lk ZW50IGluIHRoZSBzZXJ2ZXIuDQoNCiAgIENvbmZpZ3VyYXRpb24gMzogIFRo aXMgc3lzdGVtLCBhcyBpbiBjb25maWd1cmF0aW9uIDIsIGNvbnRhaW5zIGEN CiAgICAgICBjbGllbnQsIHNlcnZlciwgYW5kIGEgcHJpbnRlci4gIEluIHRo aXMgY2FzZSB0aGUgSm9iIE1JQiBhZ2VudCBpcw0KICAgICAgIGltcGxlbWVu dGVkIHdpdGhpbiB0aGUgcHJpbnRlci4NCg0KVGhlIG1vc3QgaW1wb3J0YW50 IG9iamVjdCB0byBiZSBtYXBwZWQgaXMgam1Kb2JTdWJtaXNzaW9uSUQsIHNp bmNlIHRoaXMNCmlzIGEgbWV0aG9kIGZvciB0aGUgdXNlciBvciBjbGllbnQg dG8gZGV0ZXJtaW5lIHRoZSBqbUpvYkluZGV4IGZvciBhDQpzdWJtaXR0ZWQg am9iLiAgVGhlcmVmb3JlLCBqbUpvYlN1Ym1pc3Npb25JRCBpcyBzcGVjaWZp ZWQgZm9yIGFsbCBqb2INCnN1Ym1pc3Npb24gcHJvdG9jb2xzIGRlZmluZWQg aW4gdGhpcyBkb2N1bWVudC4gIFRoZSByZW1haW5pbmcgb2JqZWN0cw0KbWFw cGVkIGluY2x1ZGUgb25seSB0aG9zZSBpdGVtcyB0aGF0IGhhdmUgdGhlIGVx dWl2YWxlbnQgaW5mb3JtYXRpb24NCnByZXNlbnRlZCB0byB0aGUgcHJpbnRl ciBieSB0aGUgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2wuDQoNCldoaWxlIHRo aXMgZG9jdW1lbnQgcGxhY2VzIGEgc3Ryb25nIGVtcGhhc2lzIG9uIGptSm9i U3VibWlzc2lvbklEDQptYXBwaW5nIHRvIG9idGFpbiBqbUpvYkluZGV4LCB0 aGUgcHJlZmVycmVkIG1ldGhvZCBpcyB0aHJvdWdoIHRoZSB1c2Ugb2YNCmEg YmktZGlyZWN0aW9uYWwgam9iIHN1Ym1pc3Npb24gcHJvdG9jb2wgdGhhdCBy ZXR1cm5zIHRoZSBlcXVpdmFsZW50DQp2YWx1ZSBvZiBqbUpvYkluZGV4IHRv IHRoZSBjbGllbnQsIHN1Y2ggYXMgSVBQLiAgV2hlbiBhIGJpLWRpcmVjdGlv bmFsDQpwcm90b2NvbCB0aGF0IHJldHVybnMgam1Kb2JJbmRleCBpcyBpbiB1 c2UsIHRoZSBqbUpvYlN1Ym1pc3Npb25JRCBvYmplY3QNCmhhcyBubyB2YWx1 ZSB0byB0aGUgY2xpZW50LiAgV2hlbiB0aGUgam1Kb2JJbmRleCBjYW5ub3Qg YmUgcmV0dXJuZWQsIHRoZQ0KdXNlIG9mIGEgY2xpZW50IGRlZmluZWQgam1K b2JTdWJtaXNzaW9uSUQgaXMgcHJlZmVycmVkIG92ZXIgYW4gYWdlbnQNCmRl cml2ZWQgdmFsdWUuICBUaGUgY2xpZW50IGRlZmluZWQgdmVyc2lvbiBhbGxv d3MgZm9yIHJldHJpZXZhbCBvZg0Kam1Kb2JJbmRleCB1c2luZyBhIHNpbmds ZSBTTk1QIEdldCBvcGVyYXRpb24sIHNpbmNlIGptSm9iU3VibWlzc2lvbklE IGlzDQp0aGUgaW5kZXggaW50byB0aGUgam1Kb2JJRFRhYmxlLiAgQW4gYWdl bnQgZGVyaXZlZCB2YWx1ZSB3aWxsIHJlcXVpcmUgYQ0Kc2VhcmNoIHRocm91 Z2ggbXVsdGlwbGUgZW50cmllcyBpbiB0aGUgam1Kb2JJRFRhYmxlLg0KDQoN Cg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwg ICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgM10NDA0KSU5URVJORVQtRFJB RlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAg ICAgRmViIDEwLCAxOTk4DQoNCg0KDQoNCg0KVGhlIG1ham9yaXR5IG9mIHRo ZSBwcm90b2NvbHMgbWFwcGVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIG9yaWVu dGVkDQp0b3dhcmRzIG5ldHdvcmsgam9iIHN1Ym1pc3Npb24uICBIb3dldmVy LCB0aGUgSm9iIE1vbml0b3JpbmcgTUlCIGlzIGFsc28NCmludGVuZGVkIHRv IG1vbml0b3IgcHJpbnQgam9icyByZWNlaXZlZCBmcm9tIG90aGVyIHRoYW4g bmV0d29yayBwb3J0cywNCnN1Y2ggYXMgcGFyYWxsZWwgYW5kIHNlcmlhbCBw b3J0cy4gIFNvbWUgb2YgdGhlIGpvYiBzdWJtaXNzaW9uIHByb3RvY29scw0K aW5jbHVkZWQgdGhhdCBhcmUgdXNlZCB3aXRoIG5vbi1uZXR3b3JrZWQgcG9y dHMgYXJlIFBKTCwgUG9zdFNjcmlwdCwgYW5kDQpUSVAvU0kuICBJbiBhZGRp dGlvbiwgdGhlIEpvYiBNb25pdG9yaW5nIE1JQiBjYW4gYmUgdXNlZCB3aXRo IHByaW50IGpvYnMNCnRoYXQgYXJlIGludGVybmFsbHkgZ2VuZXJhdGVkLCBz dWNoIGFzIHNlbGYgdGVzdCBwYWdlcy4gIEluIHRoaXMgbGF0dGVyDQpjYXNl LCBubyBtYXBwaW5nIGlzIHJlcXVpcmVkIHNpbmNlIGFsbCBqb2Igc3VibWlz c2lvbiBwcm90b2NvbHMgYXJlDQpieXBhc3NlZC4NCg0KDQoNCjIuMCAgTElO RSBQUklOVEVSIERBRU1PTiAoTFBSL0xQRCkgUFJPVE9DT0wNCg0KVGhlIExQ Ui9MUEQgcHJpbnRpbmcgcHJvdG9jb2wgW0xQRF0gaXMgdXNlZCB3aXRoIEJT RCBVTklYIHN5c3RlbXMgaW4gdGhlDQpjbGllbnQtc2VydmVyLXByaW50ZXIg Y29uZmlndXJhdGlvbi4gIFVzYWdlIG9mIHRoZSBKb2IgTW9uaXRvcmluZyBN SUINCndpdGggTFBSL0xQRCB3aWxsIG1vc3QgbGlrZWx5IGNvbmZvcm0gdG8g Q29uZmlndXJhdGlvbiAzLCB3aGVyZSB0aGUNCm1vbml0b3IgYXBwbGljYXRp b24gb3IgdGhlIHNlcnZlciB1c2VzIFNOTVAgdG8gb2J0YWluIGpvYiBpbmZv cm1hdGlvbg0KZnJvbSB0aGUgcHJpbnRlci4gIFRoZSBjbGllbnQgY29tbXVu aWNhdGVzIHdpdGggdGhlIFVOSVggc2VydmVyIHVzaW5nDQp0aGUgZXhpc3Rp bmcgTFBEIHByb3RvY29sIHRvIG9idGFpbiBqb2IgaW5mb3JtYXRpb24uDQoN ClRoZSBMUFIvTFBEIHByb3RvY29sIGlzIGFsc28gdXNlZCBpbiB0aGUgV2lu ZG93cyBlbnZpcm9ubWVudCB0bw0KaW1wbGVtZW50IHBlZXItdG8tcGVlciBw cmludGluZywgYXMgc2hvd24gaW4gY29uZmlndXJhdGlvbiAxLiAgSW4gdGhp cw0KY2FzZSwgU05NUCBpcyB1c2VkIGJ5IHRoZSBjbGllbnQgYW5kL29yIHRo ZSBtb25pdG9yIGFwcGxpY2F0aW9uIHRvDQpvYnRhaW4gdGhlIGpvYiBpbmZv cm1hdGlvbi4NCg0KT25lIG9mIHRoZSBtYWpvciBwcm9ibGVtcyBvZiBMUFIv TFBEIGlzIHRoZSBsYXJnZSBudW1iZXIgb2YgdmVuZG9yDQp1bmlxdWUgZXh0 ZW5zaW9ucyBjdXJyZW50bHkgdXNlZCB3aXRoIHRoZSBwcm90b2NvbCBhbmQg dGhlIHJlc3VsdGluZw0KY29tcGF0aWJpbGl0eSBpc3N1ZXMgYmV0d2VlbiBh dmFpbGFibGUgaW1wbGVtZW50YXRpb25zLiAgVG8gYXZvaWQgdGhlc2UNCmlz c3VlcywgdGhpcyBtYXBwaW5nIG9mIExQUi9MUEQgaXMgcmVzdHJpY3RlZCB0 byB0aGUgcHJvdG9jb2wgYXMgZGVmaW5lZA0KYnkgUkZDIDExNzkuDQoNClRo ZSBMUFIvTFBEIHByb3RvY29sIHRyYW5zZmVycyBwcmludCBqb2IgZGF0YSBh bmQgY29udHJvbCBpbmZvcm1hdGlvbiBpbg0Kc2VwYXJhdGUgZmlsZXMsIGtu b3duIGFzIHRoZSBEYXRhIEZpbGUgYW5kIENvbnRyb2wgRmlsZSwgcmVzcGVj dGl2ZWx5Lg0KTW9zdCBvZiB0aGUgaW5mb3JtYXRpb24gY29uY2VybmluZyB0 aGUgcHJpbnQgam9iIGlzIGNvbnRhaW5lZCBpbiB0aGUNCkNvbnRyb2wgRmls ZS4gIEluIG1hbnkgTFBEIGltcGxlbWVudGF0aW9ucywgdGhlIENvbnRyb2wg RmlsZSBpcw0KdHJhbnNmZXJyZWQgZm9sbG93aW5nIHRoZSBEYXRhIEZpbGUu ICBUaHVzIG11Y2ggb2YgdGhlIGluZm9ybWF0aW9uDQpjb25jZXJuaW5nIHRo ZSBqb2IgbWF5IG5vdCBiZSBhdmFpbGFibGUgdW50aWwgdGhlIGNvbXBsZXRp b24gb2YgdGhlIGRhdGENCnRyYW5zbWlzc2lvbi4NCg0KDQoyLjEgIGptSm9i U3VibWlzc2lvbklEIE1hcHBlZCB0byBMUFIvTFBEDQoNClRoZSBMUFIvTFBE IFJlY2VpdmUgRGF0YSBGaWxlIGNvbW1hbmQgY29udGFpbnMgYSBwYXJhbWV0 ZXIgd2hpY2ggZGVmaW5lcw0KdGhlIG5hbWUgb2YgdGhlIGRhdGEgZmlsZS4g IFRoaXMgbmFtZSBmaWVsZCBpcyBzdHJ1Y3R1cmVkIGFzIGZvbGxvd3M6DQoN CiAgICAgICAgZGZhWFhYPGhvc3QtbmFtZT4gIG9yICBkYVhYWFg8aG9zdC1u YW1lPg0KDQpXaGVyZSBYWFggb3IgWFhYWCBpcyB0aGUgbnVtZXJpYyBqb2Ig bnVtYmVyIGFzc2lnbmVkIGJ5IHRoZSBuZXR3b3JrDQplbnRpdHkgc3VibWl0 dGluZyB0aGUgcHJpbnQgam9iIHRvIHRoZSBwcmludGVyLiAgVGhlIHJlY29t bWVuZGVkIG1hcHBpbmcNCm9mIHRoaXMgbmFtZSBmaWVsZCB0byBqbUpvYlN1 Ym1pc3Npb25JRCBpczoNCg0KDQoNCkJlcmdtYW4gICAgICAgICAgICAgICAg ICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgIFtwYWdl IDRdDQwNCklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFBy b3RvY29sIE1hcHBpbmcgICAgICAgIEZlYiAxMCwgMTk5OA0KDQoNCg0KDQoN CiAgb2N0ZXQgMTogICAnOScNCg0KICBvY3RldHMgMi00MDogIENvbnRhaW5z IHRoZSA8aG9zdC1uYW1lPiBwb3J0aW9uIG9mIHRoZSBuYW1lIGZpZWxkLiAg SWYNCiAgICAgICAgICAgICAgICB0aGUgPGhvc3QtbmFtZT4gcG9ydGlvbiBp cyBsZXNzIHRoYW4gNDAgb2N0ZXRzLCB0aGUNCiAgICAgICAgICAgICAgICBs ZWZ0LW1vc3QgY2hhcmFjdGVyIGluIHRoZSBzdHJpbmcgc2hhbGwgYXBwZWFy IGluIG9jdGV0DQogICAgICAgICAgICAgICAgcG9zaXRpb24gMi4gIEFueSB1 bnVzZWQgcG9ydGlvbiBvZiB0aGlzIGZpZWxkIHNoYWxsIGJlDQogICAgICAg ICAgICAgICAgZmlsbGVkIHdpdGggc3BhY2VzLiAgT3RoZXJ3aXNlLCBvbmx5 IHRoZSBsYXN0IDM5IGJ5dGVzDQogICAgICAgICAgICAgICAgc2hhbGwgYmUg aW5jbHVkZWQuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAgJzAwMDAwWFhYJyBvciAn MDAwMFhYWFgnLCB3aGVyZSBYWFggb3IgWFhYWCBpcyB0aGUNCiAgICAgICAg ICAgICAgICAgZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9u IG9mIHRoZSBMUFIvTFBEDQogICAgICAgICAgICAgICAgIGpvYiBudW1iZXIu DQoNCg0KMi4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBMUFIvTFBEDQoNClRo ZSBqb2IgaW5kZXggKGptSm9iSW5kZXgpIGlzIGFzc2lnbmVkIGJ5IHRoZSBT Tk1QIGpvYiBtb25pdG9yaW5nIGFnZW50DQphbmQgaXMgaW5kZXBlbmRlbnQg b2YgdGhlIFhYWCAob3IgWFhYWCkgaW5kZXggYXNzaWduZWQgYnkgdGhlIExQ Ui9MUEQNCmNsaWVudC4gIFRoaXMgd2lsbCBhbGxvdyB0aGUgU05NUCBhZ2Vu dCB0byB0cmFjayBqb2JzIHJlY2VpdmVkIGZyb20NCm11bHRpcGxlIHNvdXJj ZXMuDQoNCg0KMi4zICBPdGhlciBNSUIgT2JqZWN0cyBNYXBwZWQgdG8gTFBS L0xQRA0KDQpNSUIgT2JqZWN0ICAgICAgICAgICAgICAgICAgICB8IExQUi9M UEQgUGFyYW1ldGVyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kam1K b2JLT2N0ZXRzUGVyQ29weVJlcXVlc3RlZCAgfCBOdW1iZXIgb2YgYnl0ZXMg YXMgZGVmaW5lZCBpbiB0aGUgRGF0YQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgRmlsZQ0Kam1Kb2JPd25lciAgICAgICAgICAgICAgICAg ICAgfCBDb250cm9sIGZpbGUgY29tbWFuZCBjb2RlID0gUCAoVXNlciBJZCkN Cg0KDQoyLjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRvIExQRA0K DQpPdGhlciBhdHRyaWJ1dGVzIHRoYXQgYXJlIGFwcGxpY2FibGUsIGJ1dCBu b3QgZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24NCnN1Y2ggYXMgYXR0cmlidXRl cyB0aGF0IG1hcCB0byBhIHZlbmRvciB1bmlxdWUgZXh0ZW5zaW9uLCBtYXkg YWxzbyBiZQ0KaW5jbHVkZWQuDQoNCk1JQiBhdHRyaWJ1dGUgICAgICAgICB8 IExQUi9MUEQgaW5mb3JtYXRpb24gICAgICAgICAgICAgfCBEYXRhIHR5cGUN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tDQpqb2JOYW1lICAgICAgICAg ICAgICAgfCBKb2IgTmFtZSAobm90ZXMgMSwgMikgICAgICAgICAgIHwgT2N0 ZXQgU3RyaW5nDQpxdWV1ZU5hbWVSZXF1ZXN0ZWQgICAgfCBRdWV1ZSBuYW1l IGZyb20gdGhlIERhdGEgRmlsZSAgIHwgT2N0ZXQgU3RyaW5nDQpmaWxlTmFt ZSAgICAgICAgICAgICAgfCBTb3VyY2UgRmlsZSBOYW1lIChub3RlcyAxLCAz KSAgIHwgT2N0ZXQgU3RyaW5nDQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4g VGhlIGluZm9ybWF0aW9uIGlzIG9wdGlvbmFsIGluIHRoZSBDb250cm9sIEZp bGUuICBUaGUgYXR0cmlidXRlDQogICAgIHNob3VsZCBiZSBpbmNsdWRlZCBp ZiBwcmVzZW50IGluIHRoZSBDb250cm9sIEZpbGUuDQogIDIuIENvbnRyb2wg ZmlsZSBjb21tYW5kIGNvZGUgPSBKLiAgSWYgdGhpcyBvcHRpb25hbCBmaWVs ZCBpcyBvbWl0dGVkDQogICAgIGZyb20gdGhlIGNvbnRyb2wgZmlsZSwgdGhl biB0aGUgYWdlbnQgcmV0dXJucyB0aGUgZmlsZSBuYW1lDQogICAgIChjb21t YW5kIGNvZGUgPSBOKSwgaWYgcHJlc2VudC4NCiAgMy4gQ29udHJvbCBmaWxl IGNvbW1hbmQgY29kZSA9IE4uDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAg ICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBb cGFnZSA1XQ0MDQpJTlRFUk5FVC1EUkFGVCAgICAgICBKb2IgU3VibWlzc2lv biBQcm90b2NvbCBNYXBwaW5nICAgICAgICBGZWIgMTAsIDE5OTgNCg0KDQoN Cg0KDQoNCg0KMy4wICBBUFBMRVRBTEsgUFJPVE9DT0wNCg0KQXBwbGVUYWxr IHdhcyBvcmlnaW5hbGx5IGRldmVsb3BlZCBhcyBhIHBlZXItdG8tcGVlciBu ZXR3b3JrIHByb3RvY29sLA0KYXMgZGVzY3JpYmVkIGluIGNvbmZpZ3VyYXRp b24gMSwgZm9yIHVzZSB3aXRoIEFwcGxlIE1hY2ludG9zaCBjb21wdXRlcnMu DQpUb2RheSwgcHJpbnQgc3Bvb2xlcnMgYXJlIGFsc28gYXZhaWxhYmxlIGZv ciB1c2Ugd2l0aCBNYWNpbnRvc2ggY29tcHV0ZXINCm5ldHdvcmtzIHRoYXQg Y29uZm9ybSB0byBjb25maWd1cmF0aW9ucyAyLzMuICBJbiBhZGRpdGlvbiwg cHJpbnRpbmcgd2l0aA0KdGhlIEFwcGxlVGFsayBwcm90b2NvbCBpcyBzdXBw b3J0ZWQgZnJvbSBib3RoIFdpbmRvd3MgTlQgc2VydmVycyBhbmQNCk5vdmVs bCBzZXJ2ZXJzIGFsc28gcGVyIGNvbmZpZ3VyYXRpb25zIDIvMy4NCg0KVGhl IEFwcGxlVGFsayBwcm90b2NvbCBwcm92aWRlcyB2ZXJ5IGxpdHRsZSBpbmZv cm1hdGlvbiB0aGF0IGNhbiBiZSB1c2VkDQp3aXRoIHRoZSBKb2IgTW9uaXRv cmluZyBNSUIuICBUaGUgTWFjaW50b3NoIHByaW50IGRyaXZlcnMgYXJlIGFi bGUgdG8NCnByb3ZpZGUgaW5mb3JtYXRpb24gY29uY2VybmluZyB0aGUgdXNl ciBhbmQgZG9jdW1lbnQgbmFtZSBidXQgaW1iZWQgdGhpcw0KaW5mb3JtYXRp b24gaW4gdGhlIFBETCwgd2hpY2ggaXMgdHlwaWNhbGx5IFBvc3RTY3JpcHQu ICBUaGUgcHJlZmVycmVkDQpqbUpvYlN1Ym1pc3Npb25JRCBpcyBjb25zdHJ1 Y3RlZCBmcm9tIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgUG9zdFNjcmlwdA0K ZmlsZSwgYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDkuMC4NCg0KDQozLjEgIGpt Sm9iU3VibWlzc2lvbklEIE1hcHBlZCB0byBBcHBsZVRhbGsNCg0KQW4gYWx0 ZXJuYXRpdmUgam1Kb2JTdWJtaXNzaW9uSUQgbWF5IGJlIGNvbnN0cnVjdGVk IGZyb20gdGhlIENvbm5lY3Rpb24NCklkZW50aWZpZXIgY29udGFpbmVkIGlu IHRoZSBBcHBsZVRhbGsgUHJpbnRlciBBY2Nlc3MgUHJvdG9jb2wgKFBBUCkN CmhlYWRlci4gIFNpbmNlIHRoZSBDb25uZWN0aW9uIElkIGlzIG5vdCByZWFk aWx5IGF2YWlsYWJsZSBpbiBhbnkgb2YgdGhlDQpkZWZpbmVkIEFwcGxlVGFs ayBpbXBsZW1lbnRhdGlvbnMsIHRoaXMgYXBwcm9hY2ggbWF5IGJlIG9mIGxp dHRsZQ0KdXRpbGl0eS4NCg0KICBvY3RldCAxOiAgICdBJw0KDQogIG9jdGV0 cyAyLTQwOiAgQ29udGFpbnMgdGhlIEFwcGxlVGFsayBwcmludGVyIG5hbWUs IHdpdGggdGhlIGZpcnN0DQogICAgICAgICAgICAgICAgY2hhcmFjdGVyIG9m IHRoZSBuYW1lIGluIG9jdGV0IDIuICBBcHBsZVRhbGsgcHJpbnRlcg0KICAg ICAgICAgICAgICAgIG5hbWVzIGFyZSBhIG1heGltdW0gb2YgMzEgY2hhcmFj dGVycy4gIEFueSB1bnVzZWQNCiAgICAgICAgICAgICAgICBwb3J0aW9uIG9m IHRoaXMgZmllbGQgc2hhbGwgYmUgZmlsbGVkIHdpdGggc3BhY2VzLg0KDQog IG9jdGV0cyA0MS00ODogICcwMDAwMFhYWCcsIHdoZXJlICdYWFgnIGlzIHRo ZSBkZWNpbWFsIChBU0NJSSBjb2RlZCkNCiAgICAgICAgICAgICAgICAgcmVw cmVzZW50YXRpb24gb2YgdGhlIENvbm5lY3Rpb24gSWQuDQoNCg0KMy4yICBP dGhlciBBcHBsZVRhbGsgTWFwcGluZ3MNCg0KTm8gb3RoZXIgSm9iIE1JQiBv YmplY3RzIG9yIHBhcmFtZXRlcnMgY2FuIGJlIGRlcml2ZWQgZnJvbSBpbmZv cm1hdGlvbg0KYXZhaWxhYmxlIGluIHRoZSBBcHBsZVRhbGsgaGVhZGVycw0K DQoNCg0KNC4wICBJTlRFUk5FVCBQUklOVElORyBQUk9UT0NPTCAoSVBQKQ0K DQpUaGUgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wgW0lQUF0gc3VwcG9y dHMgcHJpbnRpbmcgdXNpbmcgYW55IG9uZSBvZg0KdGhlIHRocmVlIHBvc3Np YmxlIGNvbmZpZ3VyYXRpb25zLiAgRm9yIGNvbmZpZ3VyYXRpb24gMiwgdGhl IG1hcHBpbmcNCmRlZmluZWQgaGVyZWluIGlzIHBlcmZvcm1lZCBvbiBhbiBh Z2VudCB3aXRoaW4gdGhlIHNlcnZlci4gIE90aGVyd2lzZSwNCnRoZSBtYXBw aW5nIGlzIHBlcmZvcm1lZCBvbiBhbiBhZ2VudCB3aXRoaW4gdGhlIHByaW50 ZXIuDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSA2XQ0MDQpJTlRF Uk5FVC1EUkFGVCAgICAgICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBw aW5nICAgICAgICBGZWIgMTAsIDE5OTgNCg0KDQoNCg0KDQo0LjEgIGptSm9i U3VibWlzc2lvbklEIE1hcHBlZCB0byBJUFANCg0KSVBQIGNvbnRhaW5zIGEg cmljaCBzZXQgb2YgcGFyYW1ldGVycyB3aGljaCBhbGxvdyBzZXZlcmFsIG1l dGhvZHMgb2YNCmNyZWF0aW5nIHRoZSBqbUpvYlN1Ym1pc3Npb25JRCBvYmpl Y3QuICBUbyBwcmV2ZW50IGludGVyb3BlcmFiaWxpdHkNCnByb2JsZW1zLCB0 aGUgcHJlZmVycmVkIG1ldGhvZCBpcyB0byB1c2UgdGhlIElQUCBqb2ItdXJp IGF0dHJpYnV0ZSBhcw0KZm9sbG93czoNCg0KICBvY3RldCAxOiAgICc0Jw0K DQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIElQUCBqb2ItdXJpIGpv YiBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUNCiAgICAgICAgICAgICAgICBnZW5l cmF0ZWQgYnkgdGhlIHByaW50ZXIuICAoVGhlIGpvYi11cmkgaXMgcmV0dXJu ZWQgdG8NCiAgICAgICAgICAgICAgICB0aGUgY2xpZW50IGJ5IElQUC4pICBJ ZiB0aGUgam9iLXVyaSBpcyBsZXNzIHRoYW4gNDANCiAgICAgICAgICAgICAg ICBvY3RldHMsIHRoZSBsZWZ0LW1vc3QgY2hhcmFjdGVyIGluIHRoZSBzdHJp bmcgc2hhbGwNCiAgICAgICAgICAgICAgICBhcHBlYXIgaW4gb2N0ZXQgcG9z aXRpb24gMi4gIEFueSB1bnVzZWQgcG9ydGlvbiBvZiB0aGlzDQogICAgICAg ICAgICAgICAgZmllbGQgc2hhbGwgYmUgZmlsbGVkIHdpdGggc3BhY2VzLiAg T3RoZXJ3aXNlLCBvbmx5IHRoZQ0KICAgICAgICAgICAgICAgIGxhc3QgMzkg Ynl0ZXMgc2hhbGwgYmUgaW5jbHVkZWQuDQoNCiAgb2N0ZXRzIDQxLTQ4OiAg Q29udGFpbnMgdGhlIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRh dGlvbiBvZg0KICAgICAgICAgICAgICAgICB0aGUgam9iLWlkIGpvYiBkZXNj cmlwdGlvbiBhdHRyaWJ1dGUuICBMZWFkaW5nIHplcm9zDQogICAgICAgICAg ICAgICAgIHNoYWxsIGJlIGluc2VydGVkIHRvIGZpbGwgdGhlIGVudGlyZSA4 IG9jdGV0IGZpZWxkLg0KDQpOT1RFIC0gU2luY2UgSVBQIHJldHVybnMgdGhl ICJqb2ItaWRlbnRpZmllciIgYXR0cmlidXRlIHdpdGggdGhlDQpqbUpvYklu ZGV4IHZhbHVlIGZvciBhIGpvYiB3aGVuIHRoZSBqb2IgaXMgc3VibWl0dGVk LCB0aGUgdXNlIG9mIHRoZQ0Kam1Kb2JTdWJtaXNzaW9uSUQgdGFibGUgc2hv dWxkIG5vdCBiZSBuZWVkZWQgYnkgYSBtYW5hZ2VtZW50DQphcHBsaWNhdGlv bi4gIFNlZSBTZWN0aW9uIDEuMC4NCg0KDQoNCjQuMiAgam1Kb2JJbmRleCBN YXBwZWQgdG8gSVBQDQoNClRoZSBqb2IgaW5kZXggKGptSm9iSW5kZXgpIGFz c2lnbmVkIGJ5IHRoZSBTTk1QIGpvYiBtb25pdG9yaW5nIGFnZW50IGlzDQpy ZXR1cm5lZCB0byB0aGUgY2xpZW50IGJ5IElQUCBhcyB0aGUgam9iLWlkIGpv YiBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUuDQooU2luY2UgSVBQIGRvZXMgbm90 IHJlcXVpcmUgY29uc2VjdXRpdmVseSBnZW5lcmF0ZWQgam9iLWlkcywgdGhl IGFnZW50DQptYXkgcmVjZWl2ZSBqb2JzIGZyb20gbXVsdGlwbGUgY2xpZW50 cyBhbmQgY2FuIGFzc2lnbiBqbUpvYkluZGV4IGluIGFuDQphc2NlbmRpbmcg c2VxdWVuY2UgaW5kZXBlbmRlbnQgb2YgdGhlIHN1Ym1pdHRpbmcgam9iIGNs aWVudC4pICBUaGUgSVBQDQpqb2ItaWQgbXVzdCBiZSByZXN0cmljdGVkIHRv IHRoZSByYW5nZSBvZiAxIHRvIDk5LDk5OSw5OTkgKGRlY2ltYWwpIHRvDQph bGxvdyB0aGUgdmFsdWUgdG8gYmUgcHJvcGVybHkgcmVwcmVzZW50ZWQgaW4g am1Kb2JTdWJtaXNzaW9uSUQuDQoNCg0KNC4zICBPdGhlciBNSUIgT2JqZWN0 cyBNYXBwZWQgdG8gSVBQDQoNCk1JQiBPYmplY3QgICAgICAgICAgICAgICAg ICAgICAgIHwgSVBQIEpvYiBhdHRyaWJ1dGUNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0Kam1Kb2JTdGF0ZSAgICAgICAgICAgICAgICAgICAgICAgfCBq b2Itc3RhdGUNCmptSm9iU3RhdGVSZWFzb25zMSAgICAgICAgICAgICAgIHwg am9iLXN0YXRlLXJlYXNvbnMgKG5vdGUgMSkNCmptTnVtYmVyT2ZJbnRlcnZl bmluZ0pvYnMgICAgICAgIHwgbnVtYmVyLW9mLWludGVydmVuaW5nLWpvYnMN CmptSm9iS09jdGV0c1BlckNvcHlSZXF1ZXN0ZWQgICAgIHwgam9iLWstb2N0 ZXRzDQpqbUpvYktPY3RldHNQcm9jZXNzZWQgICAgICAgICAgICB8IGpvYi1r LW9jdGV0cy1wcm9jZXNzZWQNCmptSm9iSW1wcmVzc2lvbnNQZXJDb3B5UmVx dWVzdGVkIHwgam9iLWltcHJlc3Npb25zDQpqbUpvYkltcHJlc3Npb25zQ29t cGxldGVkICAgICAgICB8IGpvYi1pbXByZXNzaW9ucy1jb21wbGV0ZWQNCmpt Sm9iT3duZXIgICAgICAgICAgICAgICAgICAgICAgIHwgam9iLW9yaWdpbmF0 aW5nLXVzZXItbmFtZQ0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAg ICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2Ug N10NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJv dG9jb2wgTWFwcGluZyAgICAgICAgRmViIDEwLCAxOTk4DQoNCg0KDQoNCg0K IE5vdGVzOg0KIC0tLS0tLQ0KICAxLiBqbUpvYlN0YXRlUmVhc29uczEgaXMg YSBiaXQgbWFwIHdoaWNoIGNhbiBkZXNjcmliZSB1cCB0byAzMSBqb2INCiAg ICAgc3RhdGUgcmVhc29ucy4gIEFsc28gdGhlIElQUCAiam9iLXN0YXRlLXJl YXNvbnMiIGF0dHJpYnV0ZSBpcyBhDQogICAgIG11bHRpLXZhbHVlZCBhdHRy aWJ1dGUgd2l0aCBlYWNoIHZhbHVlIGJlaW5nIGEga2V5d29yZC4gIFRoZSBJ UFANCiAgICAgY29uZGl0aW9uIG1heSBjaGFuZ2UgbXVsdGlwbGUgYml0cyBp biB0aGlzIG9iamVjdC4gIFRoZSBJUFAgImpvYi0NCiAgICAgc3RhdGUtcmVh c29ucyIgYXR0cmlidXRlIG1heSBhbHNvIGNoYW5nZSBvbmUgb3IgbW9yZSBv ZiB0aGUNCiAgICAgam9iU3RhdGVSZWFzb25zTiBhdHRyaWJ1dGVzIChzZWUg c2VjdGlvbiA0LjQpLg0KDQoNCjQuNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBN YXBwZWQgdG8gSVBQDQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJl cXVpcmVkIGlmIHRoZSBsaXN0ZWQgSVBQIGpvYiB0ZW1wbGF0ZQ0KYXR0cmli dXRlIGlzIHByb3ZpZGVkLg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAg ICB8IElQUCBqb2IgYXR0cmlidXRlICAgICAgICAgICAgfCBEYXRhIHR5cGUN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9iU3RhdGVSZWFzb25z TihOPTIsIDMsIDQpfCBqb2Itc3RhdGUtcmVhc29ucyAobm90ZSAzKSAgIHwg SW50ZWdlcg0Kam9iQ29kZWRDaGFyU2V0ICAgICAgICAgICAgfCBhdHRyaWJ1 dGVzLWNoYXJzZXQgKG5vdGUgMSkgIHwgT2N0ZXQgU3RyaW5nDQpqb2JOYXR1 cmFsTGFuZ3VhZ2VUYWcgICAgICB8IGF0dHJpYnV0ZXMtbmF0dXJhbC1sYW5n dWFnZSAgfCBPY3RldCBTdHJpbmcNCmpvYlVSSSAgICAgICAgICAgICAgICAg ICAgIHwgam9iLXVyaSAgICAgICAgICAgICAgICAgICAgICB8IE9jdGV0IFN0 cmluZw0Kam9iTmFtZSAgICAgICAgICAgICAgICAgICAgfCBqb2ItbmFtZSAg ICAgICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpwaHlzaWNhbERl dmljZSAgICAgICAgICAgICB8IG91dHB1dC1kZXZpY2UtYXNzaWduZWQgICAg ICAgfCBPY3RldCBTdHJpbmcNCm51bWJlck9mRG9jdW1lbnRzICAgICAgICAg IHwgbnVtYmVyLW9mLWRvY3VtZW50cyAgICAgICAgICB8IEludGVnZXINCmpv YlByaW9yaXR5ICAgICAgICAgICAgICAgIHwgam9iLXByaW9yaXR5ICAgICAg ICAgICAgICAgICB8IEludGVnZXINCmpvYkhvbGRVbnRpbCAgICAgICAgICAg ICAgIHwgam9iLWhvbGQtdW50aWwgICAgICAgICAgICAgICB8IE9jdGV0IFN0 cmluZw0Kc2lkZXMgICAgICAgICAgICAgICAgICAgICAgfCBzaWRlcyAobm90 ZSAyKSAgICAgICAgICAgICAgIHwgSW50ZWdlcg0KZmluaXNoaW5nICAgICAg ICAgICAgICAgICAgfCBmaW5pc2hpbmdzICAgICAgICAgICAgICAgICAgIHwg SW50ZWdlcg0KcHJpbnRRdWFsaXR5UmVxdWVzdGVkICAgICAgfCBwcmludC1x dWFsaXR5ICAgICAgICAgICAgICAgIHwgSW50ZWdlcg0KcHJpbnRlclJlc29s dXRpb25SZXF1ZXN0ZWQgfCBwcmludGVyLXJlc29sdXRpb24gICAgICAgICAg IHwgSW50ZWdlcg0Kam9iQ29waWVzUmVxdWVzdGVkICAgICAgICAgfCBjb3Bp ZXMgKG5vdGUgNCkgICAgICAgICAgICAgIHwgSW50ZWdlcg0KZG9jdW1lbnRD b3BpZXNSZXF1ZXN0ZWQgICAgfCBjb3BpZXMgKG5vdGUgNCkgICAgICAgICAg ICAgIHwgSW50ZWdlcg0Kam9iQ29sbGF0aW9uVHlwZSAgICAgICAgICAgfCBt dWx0aXBsZS1kb2N1bWVudC1oYW5kbGluZyAgIHwgSW50ZWdlcg0Kc2hlZXRz UmVxdWVzdGVkICAgICAgICAgICAgfCBqb2ItbWVkaWEtc2hlZXRzICAgICAg ICAgICAgIHwgSW50ZWdlcg0Kc2hlZXRzQ29tcGxldGVkICAgICAgICAgICAg fCBqb2ItbWVkaWEtc2hlZXRzLWNvbXBsZXRlZCAgIHwgSW50ZWdlcg0KbWVk aXVtUmVxdWVzdGVkICAgICAgICAgICAgfCBtZWRpYSAgICAgICAgICAgICAg ICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdWJtaXNzaW9uVGltZSAg ICAgICAgICB8IHRpbWUtYXQtc3VibWlzc2lvbiAgICAgICAgICAgfCBJbnRl Z2VyDQpqb2JTdGFydGVkUHJvY2Vzc2luZ1RpbWUgICB8IHRpbWUtYXQtcHJv Y2Vzc2luZyAgICAgICAgICAgfCBJbnRlZ2VyDQpqb2JDb21wbGV0aW9uVGlt ZSAgICAgICAgICB8IHRpbWUtYXQtY29tcGxldGVkICAgICAgICAgICAgfCBJ bnRlZ2VyDQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4gam9iQ29kZWRDaGFy U2V0IGlzIGFuIGVudW0gZnJvbSB0aGUgSUFOQSByZWdpc3RyeSB3aGljaCBp cyBhbHNvDQogICAgIHVzZWQgaW4gdGhlIFByaW50ZXIgTUlCLiAgVGhlIElQ UCBhdHRyaWJ1dGVzLWNoYXJzZXQgaXMgdGhlIG5hbWUNCiAgICAgKE1JTUUg cHJlZmVycmVkIG5hbWUpIG9mIHRoZSBjaGFyYWN0ZXIgc2V0Lg0KICAyLiBU aGUgSm9iIE1JQiBzaWRlcyBhdHRyaWJ1dGUgdXNlcyB0aGUgaW50ZWdlciB2 YWx1ZXMgIjEiIGFuZCAiMiIuDQogICAgIFRoZSBJUFAgc2lkZXMgYXR0cmli dXRlIHVzZXMgdGhyZWUga2V5d29yZHMuDQogIDMuIGpvYlN0YXRlUmVhc29u c04gYXJlIHRocmVlIGF0dHJpYnV0ZXMgKE49MiwgMywgNCkuICBBbHNvIHRo ZSBJUFANCiAgICAgImpvYi1zdGF0ZS1yZWFzb25zIiBhdHRyaWJ1dGUgaXMg YSBtdWx0aS12YWx1ZWQgYXR0cmlidXRlIHdpdGggZWFjaA0KICAgICB2YWx1 ZSBiZWluZyBhIGtleXdvcmQuICBUaGUgSVBQIGNvbmRpdGlvbiBtYXkgY2hh bmdlIG11bHRpcGxlIGJpdHMNCiAgICAgaW4gb25lIG9yIG1vcmUgb2YgdGhl c2UgSm9iIE1JQiBhdHRyaWJ1dGVzLiAgU2VlIGFsc28NCg0KDQoNCkJlcmdt YW4gICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAg ICAgICAgICAgICAgIFtwYWdlIDhdDQwNCklOVEVSTkVULURSQUZUICAgICAg IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgIEZlYiAx MCwgMTk5OA0KDQoNCg0KDQogICAgIGptSm9iU3RhdGVSZWFzb25zMSBpbiBz ZWN0aW9uIDQuMy4NCiAgNC4gVGhlIElQUCAiY29waWVzIiBhdHRyaWJ1dGUg bWFwcyB0byB0aGUgSm9iIE1JQjoNCiAgICAgKDEpIGpvYkNvcGllc1JlcXVl c3RlZCB3aGVuIHRoZSBqb2IgaGFzIG9ubHkgb25lIGRvY3VtZW50IE9SDQog ICAgICAgICBJUFAgIm11bHRpcGxlLWRvY3VtZW50LWhhbmRsaW5nIiBpcyAn c2luZ2xlLXZhbHVlZCcNCiAgICAgKDIpIGRvY3VtZW50Q29waWVzUmVxdWVz dGVkLCBpbiB3aGljaCBjYXNlIHRoZSBNSUIgdmFsdWUgaXMgdGhlDQogICAg ICAgICB0b3RhbCBudW1iZXIgb2YgZG9jdW1lbnQgY29waWVzIHRoYXQgdGhl IGpvYiB3aWxsIHByb2R1Y2UgYXMgYQ0KICAgICAgICAgd2hvbGUuDQoNCg0K DQo1LjAgIElOVEVMTElHRU5UIFBSSU5URVIgREFUQSBTVFJFQU0gKElQRFMp DQoNClRoZSBJUERTIGRhdGFzdHJlYW0gZmFjaWxpdGF0ZXMgYSBjbG9zZSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgcHJpbnQNCnN1cGVydmlzb3IgKFBy aW50IFNlcnZpY2VzIEZhY2lsaXR5IC0gUFNGKSBhbmQgdGhlIHByaW50ZXIu ICBUaGVyZSBhcmUNClBTRiBhcHBsaWNhdGlvbnMgZm9yIFVOSVgsIFdpbmRv d3MsIE9TLzIsIE9TLzQwMCBhbmQgaG9zdCBvcGVyYXRpbmcNCnN5c3RlbXMg c3VjaCBhcyBWTSwgTVZTIGFuZCBWU0UuIFRvZ2V0aGVyLCBQU0YgYW5kIElQ RFMgcmVwcmVzZW50IGENCmNvbXBsZXRlLCBtYXR1cmUgYW5kIHJvYnVzdCBq b2IgbWFuYWdlbWVudCBmcmFtZXdvcmsgd2hpY2ggaW5jbHVkZXMgZm9udA0K YW5kIHJlc291cmNlIG1hbmFnZW1lbnQsIHBhZ2UgcHJvZ3Jlc3MgdHJhY2tp bmcsIGpvYiBjYW5jZWxsYXRpb24sDQpjb21wbGV0ZSBlcnJvciByZWNvdmVy eSBhbmQgZW5kLXVzZXIgbm90aWZpY2F0aW9uLiAgQmVjYXVzZSBQU0YgYW5k IHRoZQ0KcHJpbnRlciBjb3JyZXNwb25kIHZpYSB0aGUgdXNlIG9mIGxvY2Fs bHkgYXNzaWduZWQgSUSScywgdGhlcmUgaXMgYQ0KbGltaXRlZCBhbW91bnQg b2YgY2xlYXIgdGV4dCBpbmZvcm1hdGlvbiBwcm92aWRlZCBkdXJpbmcgc3Vi bWlzc2lvbiBmb3INCnVzZSBieSB0aGUgSm9iIE1JQi4NCg0KDQo1LjEgIGpt Sm9iU3VibWlzc2lvbklkIE1hcHBlZCB0byBJUERTDQoNCkZvciBJUERTIG9u IHRoZSBNVlMgb3IgVlNFIHBsYXRmb3JtOg0KDQogIG9jdGV0IDE6ICAgJ0Un DQoNCiAgb2N0ZXRzIDItNDA6ICBDb250YWlucyBieXRlcyAyLTI3IG9mIHRo ZSBYT0ggRGVmaW5lIEdyb3VwIEJvdW5kYXJ5DQogICAgICAgICAgICAgICAg R3JvdXAgSUQgdHJpcGxldC4gIE9jdGV0IHBvc2l0aW9uIDIgbXVzdCBjYXJy eSB0aGUgdmFsdWUNCiAgICAgICAgICAgICAgICB4JzAxJy4gIEJ5dGVzIDI4 LTQwIG11c3QgYmUgZmlsbGVkIHdpdGggc3BhY2VzLg0KDQogIG9jdGV0cyA0 MS00ODogIENvbnRhaW5zIGEgZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJl c2VudGF0aW9uIG9mIHRoZQ0KICAgICAgICAgICAgICAgICBqbUpvYkluZGV4 IGFzc2lnbmVkIGJ5IHRoZSBhZ2VudC4gIExlYWRpbmcgemVyb3Mgc2hhbGwN CiAgICAgICAgICAgICAgICAgYmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50 aXJlIDggb2N0ZXQgZmllbGQuDQoNCg0KRm9yIElQRFMgb24gdGhlIFZNIHBs YXRmb3JtOg0KDQogIG9jdGV0IDE6ICAgJ0YnDQoNCiAgb2N0ZXRzIDItNDA6 ICBDb250YWlucyBieXRlcyAyLTMxIG9mIHRoZSBYT0ggRGVmaW5lIEdyb3Vw IEJvdW5kYXJ5DQogICAgICAgICAgICAgICAgR3JvdXAgSUQgdHJpcGxldC4g IE9jdGV0IHBvc2l0aW9uIDIgbXVzdCBjYXJyeSB0aGUgdmFsdWUNCiAgICAg ICAgICAgICAgICB4JzAyJy4gIEJ5dGVzIDMyLTQwIG11c3QgYmUgZmlsbGVk IHdpdGggc3BhY2VzLg0KDQogIG9jdGV0cyA0MS00ODogIENvbnRhaW5zIGEg ZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0K ICAgICAgICAgICAgICAgICBqbUpvYkluZGV4IGFzc2lnbmVkIGJ5IHRoZSBh Z2VudC4gIExlYWRpbmcgemVyb3Mgc2hhbGwNCiAgICAgICAgICAgICAgICAg YmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0ZXQgZmllbGQu DQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgOV0NDA0KSU5U RVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFw cGluZyAgICAgICAgRmViIDEwLCAxOTk4DQoNCg0KDQoNCkZvciBJUERTIG9u IHRoZSBPUy80MDAgcGxhdGZvcm06DQoNCiAgb2N0ZXQgMTogICAnRycNCg0K ICBvY3RldHMgMi00MDogIENvbnRhaW5zIGJ5dGVzIDItMzYgb2YgdGhlIFhP SCBEZWZpbmUgR3JvdXAgQm91bmRhcnkNCiAgICAgICAgICAgICAgICBHcm91 cCBJRCB0cmlwbGV0LiAgT2N0ZXQgcG9zaXRpb24gMiBtdXN0IGNhcnJ5IHRo ZSB2YWx1ZQ0KICAgICAgICAgICAgICAgIHgnMDMnLiAgQnl0ZXMgMzctNDAg bXVzdCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuDQoNCiAgb2N0ZXRzIDQxLTQ4 OiAgQ29udGFpbnMgYSBkZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50 YXRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAgIGptSm9iSW5kZXggYXNz aWduZWQgYnkgdGhlIGFnZW50LiAgTGVhZGluZyB6ZXJvcyBzaGFsbA0KICAg ICAgICAgICAgICAgICBiZSBpbnNlcnRlZCB0byBmaWxsIHRoZSBlbnRpcmUg OCBvY3RldCBmaWVsZC4NCg0KDQo1LjIgIFRoZSBBdHRyaWJ1dGUgR3JvdXAg TWFwcGVkIHRvIElQRFMNCg0KRm9yIE1WUy9WU0U6DQoNCk1JQiBhdHRyaWJ1 dGUgICAgICAgICAgICAgICAgICAgICB8IElQRFMgWE9IIERHQiBHcm91cCBJ RCB8IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tDQpq b2JTb3VyY2VQbGF0Zm9ybVR5cGUgc3B0TVZTKDcpICAgfCBCeXRlIDIgPSB4 JzAxJyAgICAgICAgfCBJbnRlZ2VyDQpqb2JOYW1lICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCBCeXRlcyA0LTExICAgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCg0KDQpGb3IgVk06DQoNCk1JQiBhdHRyaWJ1dGUgICAgICAgICAg ICAgICAgICAgICB8IElQRFMgWE9IIERHQiBHcm91cCBJRCB8IERhdGEgdHlw ZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tDQpqb2JTb3VyY2VQbGF0 Zm9ybVR5cGUgc3B0Vk0oOCkgICAgfCBCeXRlIDIgPSB4JzAyJyAgICAgICAg fCBJbnRlZ2VyDQpmaWxlTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAg fCBCeXRlcyA0LTExICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCg0KDQpG b3IgT1MvNDAwOg0KDQpNSUIgYXR0cmlidXRlICAgICAgICAgICAgICAgICAg ICAgfCBJUERTIFhPSCBER0IgR3JvdXAgSUQgfCBEYXRhIHR5cGUNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLQ0Kam9iU291cmNlUGxhdGZvcm1UeXBl IHNwdE9TNDAwKDkpIHwgYnl0ZSAyID0geCcwMycgICAgICAgIHwgSW50ZWdl cg0KZmlsZU5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQnl0ZXMg MjMtMzIgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JOYW1lICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCBCeXRlcyAzNy00NiAgICAgICAgICAg fCBPY3RldCBTdHJpbmcNCg0KDQoNCjYuMCAgRE9DVU1FTlQgUFJJTlRJTkcg QVBQTElDQVRJT04gKERQQSkNCg0KVGhlIElTTyAxMDE3NSBEb2N1bWVudCBQ cmludGluZyBBcHBsaWNhdGlvbiAoRFBBKSBbRFBBXSBzdXBwb3J0cw0KcHJp bnRpbmcgdXNpbmcgYW55IG9uZSBvZiB0aGUgdGhyZWUgcG9zc2libGUgY29u ZmlndXJhdGlvbnMuICBGb3INCmNvbmZpZ3VyYXRpb24gMiwgdGhlIG1hcHBp bmcgZGVmaW5lZCBoZXJlaW4gaXMgcGVyZm9ybWVkIG9uIGEgc2VydmVyLg0K T3RoZXJ3aXNlLCB0aGUgbWFwcGluZyBpcyBwZXJmb3JtZWQgb24gYW4gYWdl bnQgd2l0aGluIHRoZSBwcmludGVyLg0KDQoNCg0KDQoNCg0KDQoNCkJlcmdt YW4gICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAg ICAgICAgICAgICAgIFtwYWdlIDEwXQ0MDQpJTlRFUk5FVC1EUkFGVCAgICAg ICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBwaW5nICAgICAgICBGZWIg MTAsIDE5OTgNCg0KDQoNCg0KNi4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBw ZWQgdG8gRFBBDQoNCkRQQSBjb250YWlucyBhIHJpY2ggc2V0IG9mIHBhcmFt ZXRlcnMgd2hpY2ggYWxsb3cgc2V2ZXJhbCBtZXRob2RzIG9mDQpjcmVhdGlu ZyB0aGUgam1Kb2JTdWJtaXNzaW9uSUQgb2JqZWN0LiAgVG8gcHJldmVudCBp bnRlcm9wZXJhYmlsaXR5DQpwcm9ibGVtcywgdGhlIHByZWZlcnJlZCBtZXRo b2QgaXMgdG8gdXNlIHRoZSBEUEEgam9iLW93bmVyIGF0dHJpYnV0ZSBhcw0K Zm9sbG93czoNCg0KICBvY3RldCAxOiAgICcwJw0KDQogIG9jdGV0cyAyLTQw OiAgQ29udGFpbnMgdGhlIERQQSBqb2Itb3duZXIgYXR0cmlidXRlIHN1cHBs aWVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAgIHN1Ym1pdHRlci4gIElmIHRo ZSBqb2Itb3duZXIgaXMgbGVzcyB0aGFuIDQwIG9jdGV0cywgdGhlDQogICAg ICAgICAgICAgICAgbGVmdC1tb3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5n IHNoYWxsIGFwcGVhciBpbiBvY3RldA0KICAgICAgICAgICAgICAgIHBvc2l0 aW9uIDIuICBBbnkgdW51c2VkIHBvcnRpb24gb2YgdGhpcyBmaWVsZCBzaGFs bCBiZQ0KICAgICAgICAgICAgICAgIGZpbGxlZCB3aXRoIHNwYWNlcy4gIE90 aGVyd2lzZSwgb25seSB0aGUgbGFzdCAzOSBieXRlcw0KICAgICAgICAgICAg ICAgIHNoYWxsIGJlIGluY2x1ZGVkLg0KDQogIG9jdGV0cyA0MS00ODogIENv bnRhaW5zIGFuIDgtZGlnaXQgc2VxdWVudGlhbCBkZWNpbWFsIG51bWJlci4N Cg0KDQo2LjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIERQQQ0KDQpUaGUgam9i IGluZGV4IChqbUpvYkluZGV4KSBhc3NpZ25lZCBieSB0aGUgU05NUCBqb2Ig bW9uaXRvcmluZyBhZ2VudCBpcw0KcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBi eSBEUEEgYXMgYSBkZWNpbWFsIGRpZ2l0IHN0cmluZyBhcyB0aGUgdmFsdWUg b2YNCnRoZSBEUEEgam9iLWlkZW50aWZpZXIgYXR0cmlidXRlLiAgKFNpbmNl IERQQSBkb2VzIG5vdCByZXF1aXJlDQpjb25zZWN1dGl2ZWx5IGdlbmVyYXRl ZCBqb2ItaWRlbnRpZmllcnMsIHRoZSBhZ2VudCBtYXkgcmVjZWl2ZSBqb2Jz IGZyb20NCm11bHRpcGxlIGNsaWVudHMgYW5kIGNhbiBhc3NpZ24gdGhlIGpt Sm9iSW5kZXggaW4gYW4gYXNjZW5kaW5nIHNlcXVlbmNlDQppbmRlcGVuZGVu dCBvZiB0aGUgc3VibWl0dGluZyBqb2IgY2xpZW50LikgIFRoZSBEUEEgam9i LWlkZW50aWZpZXIgbXVzdA0KYmUgcmVzdHJpY3RlZCB0byB0aGUgcmFuZ2Ug b2YgMSB0byA5OSw5OTksOTk5IChkZWNpbWFsKSB0byBhbGxvdyB0aGUNCnZh bHVlIHRvIGJlIHByb3Blcmx5IHJlcHJlc2VudGVkIGluIGptSm9iU3VibWlz c2lvbklELg0KDQpOT1RFIC0gU2luY2UgRFBBIHJldHVybnMgdGhlICJqb2It aWRlbnRpZmllciIgYXR0cmlidXRlIHdpdGggdGhlDQpqbUpvYkluZGV4IHZh bHVlIGZvciBhIGpvYiB3aGVuIHRoZSBqb2IgaXMgc3VibWl0dGVkLCB0aGUg dXNlIG9mIHRoZQ0Kam1Kb2JTdWJtaXNzaW9uSUQgdGFibGUgc2hvdWxkIG5v dCBiZSBuZWVkZWQgYnkgYSBtYW5hZ2VtZW50DQphcHBsaWNhdGlvbi4gIFNl ZSBTZWN0aW9uIDEuMC4NCg0KDQo2LjMgIE90aGVyIE1JQiBPYmplY3RzIE1h cHBlZCB0byBEUEENCg0KTUlCIE9iamVjdCAgICAgICAgICAgICAgICAgICAg ICAgfCBEUEEgSm9iIGF0dHJpYnV0ZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0Kam1Kb2JTdGF0ZSAgICAgICAgICAgICAgICAgICAgICAgfCBqb2It c3RhdGUNCmptSm9iU3RhdGVSZWFzb25zMSAgICAgICAgICAgICAgIHwgam9i LXN0YXRlLXJlYXNvbnMgKG5vdGUgMikNCmptTnVtYmVyT2ZJbnRlcnZlbmlu Z0pvYnMgICAgICAgIHwgaW50ZXJ2ZW5pbmctam9icw0Kam1Kb2JLT2N0ZXRz UGVyQ29weVJlcXVlc3RlZCAgICAgfCB0b3RhbC1qb2Itb2N0ZXRzIChub3Rl cyAxLCAzKQ0Kam1Kb2JLT2N0ZXRzUHJvY2Vzc2VkICAgICAgICAgICAgfCBq b2Itb2N0ZXRzLWNvbXBsZXRlZCAobm90ZSAxKQ0Kam1Kb2JJbXByZXNzaW9u c1BlckNvcHlSZXF1ZXN0ZWQgfCBqb2ItaW1wcmVzc2lvbi1jb3VudCAobm90 ZSAzKQ0Kam1Kb2JJbXByZXNzaW9uc0NvbXBsZXRlZCAgICAgICAgfCBpbXBy ZXNzaW9ucy1jb21wbGV0ZWQNCmptSm9iT3duZXIgICAgICAgICAgICAgICAg ICAgICAgIHwgam9iLW93bmVyDQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4g am1Kb2JLT2N0ZXRzUGVyQ29weVJlcXVlc3RlZCBhbmQgam1Kb2JLT2N0ZXRz UHJvY2Vzc2VkIGlzIGluIEsNCg0KDQoNCkJlcmdtYW4gICAgICAgICAgICAg ICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgIFtw YWdlIDExXQ0MDQpJTlRFUk5FVC1EUkFGVCAgICAgICBKb2IgU3VibWlzc2lv biBQcm90b2NvbCBNYXBwaW5nICAgICAgICBGZWIgMTAsIDE5OTgNCg0KDQoN Cg0KICAgICBvY3RldHMgd2hpbGUgdGhlIERQQSBqb2ItdG90YWwtb2N0ZXRz IGFuZCBqb2Itb2N0ZXRzLWNvbXBsZXRlZCBpcw0KICAgICBpbiBvY3RldHMg YW5kIGlzIDYzLWJpdHMgb2Ygc2lnbmlmaWNhbmNlLg0KICAyLiBqbUpvYlN0 YXRlUmVhc29uczEgaXMgYSBiaXQgbWFwIHdoaWNoIGNhbiBkZXNjcmliZSB1 cCB0byAzMSBqb2INCiAgICAgc3RhdGUgcmVhc29ucy4gIEFsc28gdGhlIERQ QSAiam9iLXN0YXRlLXJlYXNvbnMiIGF0dHJpYnV0ZSBpcyBhDQogICAgIG11 bHRpLXZhbHVlZCBhdHRyaWJ1dGUgd2l0aCBlYWNoIHZhbHVlIGJlaW5nIGFu IG9iamVjdCBpZGVudGlmaWVyDQogICAgIChPSUQpLiAgVGhlIERQQSBjb25k aXRpb24gbWF5IGNoYW5nZSBtdWx0aXBsZSBiaXRzIGluIHRoaXMgb2JqZWN0 Lg0KICAgICBUaGUgRFBBIGNvbmRpdGlvbiBtYXkgYWxzbyBjaGFuZ2Ugb25l IG9yIG1vcmUgb2YgdGhlDQogICAgIGpvYlN0YXRlUmVhc29uc04gYXR0cmli dXRlcyAoc2VlIHNlY3Rpb24gNC40KQ0KICAzLiBEUEEgb2N0ZXRzIGluY2x1 ZGUgdGhlIG11bHRpcGxpY2F0aW9uIGZhY3RvciBkdWUgdG8gam9iIGFuZA0K ICAgICBkb2N1bWVudCBjb3BpZXMsIHdoaWxlIHRoZSBNSUIgdmFsdWVzIGRv IG5vdC4NCg0KDQo2LjQgIFRoZSBBdHRyaWJ1dGUgR3JvdXAgTWFwcGVkIHRv IERQQQ0KDQpUaGUgZm9sbG93aW5nIG1hcHBpbmdzIGFyZSByZXF1aXJlZCBp ZiB0aGUgbGlzdGVkIERQQSBqb2IgYXR0cmlidXRlIGlzDQpwcm92aWRlZC4N Cg0KTUlCIGF0dHJpYnV0ZSAgICAgICAgICAgICAgfCBEUEEgam9iIGF0dHJp YnV0ZSAgICAgICAgICAgIHxJUFAgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0NCmpvYlN0YXRlUmVhc29uc04oTj0yLCAzLCA0KXwg am9iLXN0YXRlLXJlYXNvbnMgKG5vdGUgMikgICB8IEludGVnZXINCmpvYkNv ZGVkQ2hhclNldCAgICAgICAgICAgIHwgKG5vdGUgMSkgICAgICAgICAgICAg ICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9iQWNjb3VudE5hbWUgICAgICAg ICAgICAgfCBhY2NvdW50aW5nLWluZm9ybWF0aW9uICAgICAgIHwgT2N0ZXQg U3RyaW5nDQpqb2JOYW1lICAgICAgICAgICAgICAgICAgICB8IGpvYi1uYW1l ICAgICAgICAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmRldmljZU5h bWVSZXF1ZXN0ZWQgICAgICAgIHwgcHJpbnRlci1uYW1lLXJlcXVlc3RlZCAg ICAgICB8IE9jdGV0IFN0cmluZw0KcGh5c2ljYWxEZXZpY2UgICAgICAgICAg ICAgfCBwcmludGVycy1hc3NpZ25lZCAgICAgICAgICAgIHwgT2N0ZXQgU3Ry aW5nDQpudW1iZXJPZkRvY3VtZW50cyAgICAgICAgICB8IG51bWJlci1vZi1k b2N1bWVudHMgICAgICAgICAgfCBJbnRlZ2VyDQpmaWxlTmFtZSAgICAgICAg ICAgICAgICAgICB8IGZpbGUtbmFtZSAgICAgICAgICAgICAgICAgICAgfCBP Y3RldCBTdHJpbmcNCmRvY3VtZW50TmFtZSAgICAgICAgICAgICAgIHwgZG9j dW1lbnQtbmFtZSAgICAgICAgICAgICAgICB8IE9jdGV0IFN0cmluZw0Kam9i Q29tbWVudCAgICAgICAgICAgICAgICAgfCBqb2ItY29tbWVudCAgICAgICAg ICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpkb2N1bWVudEZvcm1hdCAgICAg ICAgICAgICB8IGRvY3VtZW50LWZvcm1hdCAgICAgICAgICAgICAgfCBPY3Rl dCBTdHJpbmcNCmpvYlByaW9yaXR5ICAgICAgICAgICAgICAgIHwgam9iLXBy aW9yaXR5ICAgICAgICAgICAgICAgICB8IEludGVnZXINCmpvYlByb2Nlc3NB ZnRlckRhdGVBbmRUaW1lIHwgam9iLXByaW50LWFmdGVyICAgICAgICAgICAg ICB8IE9jdGV0IFN0cmluZw0Kb3V0cHV0QmluICAgICAgICAgICAgICAgICAg fCByZXN1bHRzLXByb2ZpbGUub3V0cHV0LWJpbiAgIHwgT2N0ZXQgU3RyaW5n DQpzaWRlcyAgICAgICAgICAgICAgICAgICAgICB8IHNpZGVzIChub3RlIDMp ICAgICAgICAgICAgICAgfCBJbnRlZ2VyDQpmaW5pc2hpbmcgICAgICAgICAg ICAgICAgICB8IGpvYi1maW5pc2hpbmcsIGZpbmlzaGluZyAgICAgfCBJbnRl Z2VyDQpwcmludFF1YWxpdHlSZXF1ZXN0ZWQgICAgICB8IHByaW50LXF1YWxp dHkgICAgICAgICAgICAgICAgfCBJbnRlZ2VyDQpwcmludGVyUmVzb2x1dGlv blJlcXVlc3RlZCB8IGRlZmF1bHQtcHJpbnRlci1yZXNvbHV0aW9uICAgfCBJ bnRlZ2VyDQogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAobm90ZSA0 KSAgICAgICAgICAgICAgICAgICAgfA0Kam9iQ29waWVzUmVxdWVzdGVkICAg ICAgICAgfCByZXN1bHRzLXByb2ZpbGUuam9iLWNvcGllcyAgIHwgSW50ZWdl cg0Kam9iQ29waWVzQ29tcGxldGVkICAgICAgICAgfCBqb2ItY29waWVzLWNv bXBsZXRlZCAgICAgICAgIHwgSW50ZWdlcg0KZG9jdW1lbnRDb3BpZXNSZXF1 ZXN0ZWQgICAgfCBjb3B5LWNvdW50IChub3RlIDUpICAgICAgICAgIHwgSW50 ZWdlcg0KZG9jdW1lbnRDb3BpZXNDb21wbGV0ZWQgICAgfCBjb3BpZXMtY29t cGxldGVkIChub3RlIDYpICAgIHwgSW50ZWdlcg0Kc2hlZXRzUmVxdWVzdGVk ICAgICAgICAgICAgfCBqb2ItbWVkaWEtc2hlZXQtY291bnQgICAgICAgIHwg SW50ZWdlcg0Kc2hlZXRzQ29tcGxldGVkICAgICAgICAgICAgfCBqb2ItbWVk aWEtc2hlZXRzLWNvbXBsZXRlZCAgIHwgSW50ZWdlcg0KcGFnZXNSZXF1ZXN0 ZWQgICAgICAgICAgICAgfCBqb2ItcGFnZS1jb3VudCAgICAgICAgICAgICAg IHwgSW50ZWdlcg0KcGFnZXNDb21wbGV0ZWQgICAgICAgICAgICAgfCBwYWdl cy1jb21wbGV0ZWQgICAgICAgICAgICAgIHwgSW50ZWdlcg0KbWVkaXVtUmVx dWVzdGVkICAgICAgICAgICAgfCBwYWdlLW1lZGlhLXNlbGVjdCwgICAgICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICBkZWZhdWx0LW1lZGl1bSAgICAgICAgICAgICAgfA0Kam9iU3VibWlz c2lvblRpbWUgICAgICAgICAgfCBzdWJtaXNzaW9uLXRpbWUgKG5vdGUgNykg ICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdGFydGVkUHJvY2Vzc2luZ1RpbWUg ICB8IHN0YXJ0ZWQtcHJpbnRpbmctdGltZSAobm90ZSA3KSBPY3RldCBTdHJp bmcNCmpvYkNvbXBsZXRpb25UaW1lICAgICAgICAgIHwgY29tcGxldGlvbi10 aW1lIChub3RlIDcpICAgICB8IE9jdGV0IFN0cmluZw0KDQoNCg0KDQpCZXJn bWFuICAgICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAg ICAgICAgICAgICAgICBbcGFnZSAxMl0NDA0KSU5URVJORVQtRFJBRlQgICAg ICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgRmVi IDEwLCAxOTk4DQoNCg0KDQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4gRXZl cnkgRFBBIGF0dHJpYnV0ZSBpcyB0YWdnZWQgaW5kaWNhdGluZyB0aGUgY29k ZWQgY2hhcmFjdGVyIHNldA0KICAgICB0byBiZSB1c2VkIGZvciB0aGF0IGF0 dHJpYnV0ZS4NCiAgMi4gam9iU3RhdGVSZWFzb25zTiBhcmUgdGhyZWUgYXR0 cmlidXRlcyAoTj0yLCAzLCA0KS4gIFRoZSBEUEENCiAgICAgY29uZGl0aW9u IG1heSBjaGFuZ2Ugb25lIG9yIG1vcmUgb2YgdGhlIGJpdHMgaW4gb25lIG9y IG1vcmUgb2YNCiAgICAgdGhlc2UgSm9iIE1JQiBpdGVtcy4gIEFsc28gdGhl IERQQSBqb2Itc3RhdGUtcmVhc29ucyBpcyBhIG11bHRpLQ0KICAgICB2YWx1 ZWQgYXR0cmlidXRlIHdpdGggZWFjaCB2YWx1ZSBiZWluZyBhbiBPQkpFQ1Qg SURFTlRJRklFUiAoT0lEKS4NCiAgMy4gVGhlIEpvYiBNSUIgc2lkZXMgYXR0 cmlidXRlIGlzIGFuIGludGVnZXIgJzEnIG9yICcyJyB3aGlsZSB0aGUgRFBB DQogICAgIHNpZGVzIGF0dHJpYnV0ZSBoYXMgb25lIG9mIHNpeCBPSUQgdmFs dWVzIHRoYXQgaW5jbHVkZXMgcGxleC4NCiAgNC4gcHJpbnRlclJlc29sdXRp b25SZXF1ZXN0ZWQgaGFzIHggYW5kIHkgcmVzb2x1dGlvbiBhbmQgaXMgaW50 ZW5kZWQNCiAgICAgdG8gb3ZlcnJpZGUgdGhlIHJlc29sdXRpb24gaW5zdHJ1 Y3Rpb24gaW4gdGhlIGRvY3VtZW50LCBpZiBhbnksDQogICAgIHdoaWxlIHRo ZSBEUEEgZGVmYXVsdC1wcmludGVyLXJlc29sdXRpb24gaXMgdGhlIHNhbWUg aW4geCBhbmQgeSBhbmQNCiAgICAgb25seSB0YWtlcyBlZmZlY3QgaWYgdGhl IGRvY3VtZW50IGRvZXMgbm90IGNvbnRhaW4gYSByZXNvbHV0aW9uDQogICAg IGluc3RydWN0aW9uDQogIDUuIFRoZSBEUEEgImNvcHktY291bnQiIGF0dHJp YnV0ZSBpcyBhIHBlci1kb2N1bWVudCBhdHRyaWJ1dGUsIHNvIHRoZQ0KICAg ICBNSUIgdmFsdWUgaXMgdGhlIHN1bSBvZiB0aGUgZG9jdW1lbnRzJyAiY29w eS1jb3VudCIgdmFsdWVzIHRpbWVzDQogICAgIHRoZSBqb2IncyAicmVzdWx0 cy1wcm9maWxlLmpvYi1jb3BpZXMiIHZhbHVlLg0KICA2LiBUaGUgRFBBICJj b3BpZXMtY29tcGxldGVkIiBhdHRyaWJ1dGUgaXMgYSBwZXItZG9jdW1lbnQg YXR0cmlidXRlLA0KICAgICBzbyB0aGUgTUlCIHZhbHVlIGlzIHRoZSBzdW0g b2YgdGhlIGRvY3VtZW50cycgImNvcGllcy1jb21wbGV0ZWQiDQogICAgIHZh bHVlcyB0aW1lcyB0aGUgam9iJ3MgInJlc3VsdHMtcHJvZmlsZS5qb2ItY29w aWVzIiB2YWx1ZS4NCiAgNy4gVGhlIERQQSBHZW5lcmF0bGl6ZWRUaW1lIGRh dGEgdHlwZSBpcyBkZWZpbmVkIGJ5IElTTyA4ODI0DQogICAgIChJU08tODgy NCkgd2hpbGUgdGhlIE1JQiBEYXRlQW5kVGltZSBpcyBkZWZpbmVkIGJ5IFNO TVB2Mi1UQw0KICAgICAoU05NUHYyLVRDKS4NCg0KDQoNCjcuMCAgTk9WRUxM IERJU1RSSUJVVEVEIFBSSU5UIFNFUlZJQ0UgKE5EUFMpDQoNCk5vdmVsbCBE aXN0cmlidXRlZCBQcmludCBTZXJ2aWNlcyBpcyBhIERQQSBiYXNlZCBqb2Ig c3VibWlzc2lvbiBwcm90b2NvbA0KdGhhdCBjb25mb3JtcyB0byBjb25maWd1 cmF0aW9uIDMuDQoNCg0KNy4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQg dG8gTkRQUw0KDQpORFBTIHN1cHBvcnRzIHRoZSBnZW5lcmF0aW9uIG9mIGEg cHJvcGVybHkgZm9ybWF0dGVkIGptSm9iU3VibWlzc2lvbklEDQpmb3IgdXNl IGluIHRoZSBKb2IgTUlCLCB2aWEgdGhlIGF0dHJpYnV0ZSBuZHBzLWF0dC1q b2ItaWRlbnRpZmllci4NCg0KDQo3LjIgIGptSm9iSW5kZXggTWFwcGVkIHRv IE5EUFMNCg0KTkRQUyBkZWZpbmVzIHRoZSBhdHRyaWJ1dGUgbmRwcy1hdHQt am9iLWlkZW50aWZpZXItb24tcHJpbnRlciB0aGF0IGNhbg0KYmUgdXNlZCB0 byByZXR1cm4gdGhlIHZhbHVlIG9mIGptSm9iSW5kZXggdG8gdGhlIE5EUFMg Y2xpZW50LiBTZWUNClNlY3Rpb24gMS4wLg0KDQoNCjcuMyAgT3RoZXIgTUlC IE9iamVjdHMgTWFwcGVkIHRvIE5EUFMNCg0KTUlCIE9iamVjdCAgICAgICAg ICAgICAgICAgICAgICAgfCBORFBTIFBhcmFtZXRlcg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpqbUpvYlN0YXRlICAgICAgICAgICAgICAgICAg ICAgICB8IG5kcHMtYXR0LWN1cnJlbnQtam9iLXN0YXRlIChub3RlIDEpDQpq bUpvYlN0YXRlUmVhc29uczEgICAgICAgICAgICAgICB8IG5kcHMtYXR0LWpv Yi1zdGF0ZS1yZWFzb25zIChub3RlIDIpDQoNCg0KDQpCZXJnbWFuICAgICAg ICAgICAgICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAg ICAgICBbcGFnZSAxM10NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1 Ym1pc3Npb24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgRmViIDEwLCAxOTk4 DQoNCg0KDQoNCmptTnVtYmVyT2ZJbnRlcnZlbmluZ0pvYnMgICAgICAgIHwg bmRwcy1hdHQtaW50ZXJ2ZW5pbmctam9icw0Kam1Kb2JLT2N0ZXRzUGVyQ29w eVJlcXVlc3RlZCAgICAgfCBuZHBzLWF0dC10b3RhbC1qb2Itb2N0ZXRzIChu b3RlcyAzLDQpDQpqbUpvYktPY3RldHNQcm9jZXNzZWQgICAgICAgICAgICB8 IG5kcHMtYXR0LW9jdGV0cy1jb21wbGV0ZWQgKG5vdGUgMykNCmptSm9iSW1w cmVzc2lvbnNQZXJDb3B5UmVxdWVzdGVkIHwgbmRwcy1hdHQtam9iLWltcHJl c3Npb25zLWNvdW50DQpqbUpvYkltcHJlc3Npb25zQ29tcGxldGVkICAgICAg ICB8IG5kcHMtYXR0LWltcHJlc3Npb25zLWNvbXBsZXRlZA0Kam1Kb2JPd25l ciAgICAgICAgICAgICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2Itb3duZXIg KG5vdGUgNSkNCg0KIE5vdGVzOg0KIC0tLS0tLQ0KICAxLiBTb21lIG9mIHRo ZSBORFBTIGpvYiBzdGF0ZXMgbXVzdCBiZSByZXByZXNlbnRlZCBieSBib3Ro IGENCiAgICAgam1Kb2JTdGF0ZSBhbmQgYSBqbUpvYlN0YXRlUmVhc29uczEg b2JqZWN0IG9yIGEgam9iU3RhdGVSZWFzb25zTg0KICAgICBhdHRyaWJ1dGUg KE49MiwgMywgNCkuDQogIDIuIFRoZSBORFBTIGpvYiBzdGF0ZSByZWFzb25z IG1heSBiZSBtYXBwZWQgdG8gZWl0aGVyIHRoZSBvYmplY3QNCiAgICAgam1K b2JTdGF0ZVJlYXNvbnMxIG9yIHRoZSBhdHRyaWJ1dGUgam9iU3RhdGVSZWFz b25zTiAoTj0yLCAzLCA0KS4NCiAgMy4gam1Kb2JLT2N0ZXRzUGVyQ29weVJl cXVlc3RlZCBhbmQgam1Kb2JLT2N0ZXRzUHJvY2Vzc2VkIGlzIGluIEsNCiAg ICAgb2N0ZXRzIHdoaWxlIHRoZSBORFBTIG5kcHMtYXR0LWpvYi10b3RhbC1v Y3RldHMgYW5kDQogICAgIG5kcHMtYXR0LWpvYi1vY3RldHMtY29tcGxldGVk IGlzIGluIG9jdGV0cyBhbmQgaXMgNjMtYml0cyBvZg0KICAgICBzaWduaWZp Y2FuY2UuDQogIDQuIE5EUFMgb2N0ZXRzIGluY2x1ZGUgdGhlIG11bHRpcGxp Y2F0aW9uIGZhY3RvciBkdWUgdG8gam9iIGFuZA0KICAgICBkb2N1bWVudCBj b3BpZXMsIHdoaWxlIHRoZSBNSUIgdmFsdWVzIGRvIG5vdC4NCiAgNS4gVGhl IEpvYiBNSUIgb2JqZWN0IG11c3QgYmUgbXVsdGlwbGllZCBieSB0aGUgYXR0 cmlidXRlDQogICAgIGpvYkNvcGllc1JlcXVlc3RlZCB0byBvYnRhaW4gdGhl IE5EUFMgYXR0cmlidXRlIHZhbHVlLCBpZiBtdWx0aXBsZQ0KICAgICBjb3Bp ZXMgaGF2ZSBiZWVuIHJlcXVlc3RlZC4NCg0KDQo3LjQgIFRoZSBBdHRyaWJ1 dGUgR3JvdXAgTWFwcGVkIHRvIE5EUFMNCg0KVGhlIGZvbGxvd2luZyBtYXBw aW5ncyBhcmUgcmVxdWlyZWQgaWYgdGhlIGxpc3RlZCBQSkwgYXR0cmlidXRl IG9yDQpjb21tYW5kIG9wdGlvbiBpcyBwcm92aWRlZC4NCg0KTUlCIGF0dHJp YnV0ZSAgICAgICAgICAgICAgfCBORFBTIHBhcmFtZXRlciAgICAgICAgICAg ICAgIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0N CmpvYlN0YXRlUmVhc29uc04oTj0yLCAzLCA0KXwgbmRwcy1qb2Itc3RhdGUt cmVhc29ucyAgICAgICB8IEludGVnZXINCmpvYkFjY291bnROYW1lICAgICAg ICAgICAgIHwgbmRwcy1hdHQtam9iLW93bmVyICAgICAgICAgICB8IE9jdGV0 IFN0cmluZw0Kam9iTmFtZSAgICAgICAgICAgICAgICAgICAgfCBuZHBzLWF0 dC1qb2ItbmFtZSAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JPcmln aW5hdGluZ0hvc3QgICAgICAgICB8IG5kcHMtYXR0LWpvYi1vcmlnaW5hdG9y ICAgICAgfCBPY3RldCBTdHJpbmcNCmRldmljZU5hbWVSZXF1ZXN0ZWQgICAg ICAgIHwgbmRwcy1hdHQtcHJpbnRlci1uYW1lLS0gICAgICB8IE9jdGV0IFN0 cmluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgcmVxdWVzdGVk ICAgICAgICAgICAgICAgICAgIHwNCm51bWJlck9mRG9jdW1lbnRzICAgICAg ICAgIHwgbmRwcy1hdHQtbnVtYmVyLW9mLWRvY3VtZW50cyB8IEludGVnZXIN CmZpbGVOYW1lICAgICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQtZG9jdW1l bnQtZmlsZS1uYW1lICB8IE9jdGV0IFN0cmluZw0KZG9jdW1lbnROYW1lICAg ICAgICAgICAgICAgfCBuZHBzLWF0dC1kb2N1bWVudC1uYW1lICAgICAgIHwg T2N0ZXQgU3RyaW5nDQpqb2JDb21tZW50ICAgICAgICAgICAgICAgICB8IG5k cHMtYXR0LWpvYi1jb21tZW50ICAgICAgICAgfCBPY3RldCBTdHJpbmcNCmRv Y3VtZW50Rm9ybWF0SW5kZXggICAgICAgIHwgbmRwcy1hdHQtcHJ0SW50ZXJw cmV0ZXJJbmRleCB8IEludGVnZXINCmRvY3VtZW50Rm9ybWF0ICAgICAgICAg ICAgIHwgbmRwcy1hdHQtZG9jdW1lbnQtZm9ybWF0ICAgICB8IEludGVnZXIN CmpvYlByaW9yaXR5ICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQtam9iLXBy aW9yaXR5ICAgICAgICB8IEludGVnZXINCmpvYlByb2Nlc3NBZnRlckRhdGVB bmRUaW1lIHwgbmRwcy1hdHQtam9iLXByaW50LWFmdGVyICAgICB8IE9jdGV0 IFN0cmluZw0Kb3V0cHV0QmluICAgICAgICAgICAgICAgICAgfCBuZHBzLWF0 dC1yZXN1bHRzLXByb2ZpbGUgICAgIHwgSW50ZWdlcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgKG5vdGUgMSkgICAgICAgICAgICAgICAgICAg IHwNCnNpZGVzICAgICAgICAgICAgICAgICAgICAgIHwgbmRwcy1hdHQtc2lk ZXMgKG5vdGUgMikgICAgICB8IEludGVnZXINCmZpbmlzaGluZyAgICAgICAg ICAgICAgICAgIHwgbmRwcy1hdHQtam9iLWZpbmlzaGluZyAgICAgICB8IElu dGVnZXINCnByaW50UXVhbGl0eVJlcXVlc3RlZCAgICAgIHwgbmRwcy1hdHQt cHJpbnQtcXVhbGl0eSAgICAgICB8IEludGVnZXINCg0KDQoNCg0KQmVyZ21h biAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAg ICAgICAgICAgICAgW3BhZ2UgMTRdDQwNCklOVEVSTkVULURSQUZUICAgICAg IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgIEZlYiAx MCwgMTk5OA0KDQoNCg0KDQpwcmludGVyUmVzb2x1dGlvblJlcXVlc3RlZCB8 IG5kcHMtYXR0LWRlZmF1bHQtcHJpbnRlci0tICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgcmVzb2x1dGlvbiAobm90ZSAzKSAgICAgICAg IHwgSW50ZWdlcg0KcHJpbnRlclJlc29sdXRpb25Vc2VkICAgICAgfCBuZHBz LWF0dC1kZWZhdWx0LXJlc29sdXRpb25zLS0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgIHVzZWQgICAgICAgICAgICAgICAgICAgICAgICB8IElu dGVnZXINCmpvYkNvcGllc1JlcXVlc3RlZCAgICAgICAgIHwgbmRwcy1hdHQt cmVzdWx0cy1wcm9maWxlICAgICB8IEludGVnZXINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIChub3RlIDQpICAgICAgICAgICAgICAgICAgICB8 DQpqb2JDb3BpZXNDb21wbGV0ZWQgICAgICAgICB8IG5kcHMtYXR0LWpvYi1j b3BpZXMtY29tcGxldGVkfCBJbnRlZ2VyDQpkb2N1bWVudENvcGllc1JlcXVl c3RlZCAgICB8IG5kcHMtYXR0LWNvcHktY291bnQgKG5vdGUgNSkgfCBJbnRl Z2VyDQpkb2N1bWVudENvcGllc0NvbXBsZXRlZCAgICB8IG5kcHMtYXR0LWNv cGllcy1jb21wbGV0ZWQgICAgfCBJbnRlZ2VyDQogICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAobm90ZSA2KSAgICAgICAgICAgICAgICAgICAgfA0K c2hlZXRzUmVxdWVzdGVkICAgICAgICAgICAgfCBuZHBzLWF0dC1qb2ItbWVk aWEtLSAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg IHNoZWV0LWNvdW50ICAgICAgICAgICAgICAgICB8IEludGVnZXINCnNoZWV0 c0NvbXBsZXRlZCAgICAgICAgICAgIHwgbmRwcy1hdHQtbWVkaWEtc2hlZXRz LS0gICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBjb21w bGV0ZWQgICAgICAgICAgICAgICAgICAgfCBJbnRlZ2VyDQptZWRpdW1Db25z dW1lZCAgICAgICAgICAgICB8IG5kcHMtYXR0LW1lZGlhLXVzZWQgICAgICAg ICAgfCBJbnRlZ2VyDQpqb2JTdWJtaXNzaW9uVG9TZXJ2ZXJUaW1lICB8IG5k cHMtYXR0LXN1Ym1pc3Npb24tdGltZSAgICAgfCBPY3RldCBTdHJpbmcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChub3RlIDcpICAgICAgICAg ICAgICAgICAgICB8DQpqb2JTdWJtaXNzaW9uVGltZSAgICAgICAgICB8IG5k cHMtYXR0LXN0YXJ0ZWQtcHJpbnRpbmctdGltZSBPY3RldCBTdHJpbmcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChub3RlIDcpICAgICAgICAg ICAgICAgICAgICB8DQpqb2JDb21wbGV0aW9uVGltZSAgICAgICAgICB8IG5k cHMtYXR0LWNvbXBsZXRpb24tdGltZSAgICAgfCBPY3RldCBTdHJpbmcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIChub3RlIDcpICAgICAgICAg ICAgICAgICAgICB8DQoNCiBOb3RlczoNCiAtLS0tLS0NCiAgMS4gVGhlIG91 dHB1dC1iaW4gZmllbGQgaW4gbmRwcy1hdHQtcmVzdWx0cy1wcm9maWxlIGlz IHRvIGJlIHVzZWQuDQogIDIuIFRoZSBKb2IgTUlCIHNpZGVzIGF0dHJpYnV0 ZSBpcyBhbiBpbnRlZ2VyICcxJyBvciAnMicgd2hpbGUgdGhlIE5EUFMNCiAg ICAgc2lkZXMgYXR0cmlidXRlIGhhcyBvbmUgb2Ygc2l4IE9JRCB2YWx1ZXMg dGhhdCBpbmNsdWRlcyBwbGV4Lg0KICAzLiBwcmludGVyUmVzb2x1dGlvblJl cXVlc3RlZCBoYXMgeCBhbmQgeSByZXNvbHV0aW9uIGFuZCBpcyBpbnRlbmRl ZA0KICAgICB0byBvdmVycmlkZSB0aGUgcmVzb2x1dGlvbiBpbnN0cnVjdGlv biBpbiB0aGUgZG9jdW1lbnQsIGlmIGFueSwNCiAgICAgd2hpbGUgdGhlIG5k cHMtYXR0LWRlZmF1bHQtcHJpbnRlci1yZXNvbHV0aW9uIGlzIHRoZSBzYW1l IGluIHggYW5kDQogICAgIHkgYW5kIG9ubHkgdGFrZXMgZWZmZWN0IGlmIHRo ZSBkb2N1bWVudCBkb2VzIG5vdCBjb250YWluIGENCiAgICAgcmVzb2x1dGlv biBpbnN0cnVjdGlvbg0KICA0LiBUaGUgam9iLWNvcGllcyBmaWVsZCBpbiBu ZHBzLWF0dC1yZXN1bHRzLXByb2ZpbGUgaXMgdG8gYmUgdXNlZC4NCiAgNS4g VGhlIE5EUFMgImNvcHktY291bnQiIGF0dHJpYnV0ZSBpcyBhIHBlci1kb2N1 bWVudCBhdHRyaWJ1dGUsIHNvIHRoZQ0KICAgICBNSUIgdmFsdWUgaXMgdGhl IHN1bSBvZiB0aGUgZG9jdW1lbnRzJyAiY29weS1jb3VudCIgdmFsdWVzIHRp bWVzDQogICAgIHRoZSBqb2IncyAicmVzdWx0cy1wcm9maWxlLmpvYi1jb3Bp ZXMiIHZhbHVlLg0KICA2LiBUaGUgTkRQUyAiY29waWVzLWNvbXBsZXRlZCIg YXR0cmlidXRlIGlzIGEgcGVyLWRvY3VtZW50IGF0dHJpYnV0ZSwNCiAgICAg c28gdGhlIE1JQiB2YWx1ZSBpcyB0aGUgc3VtIG9mIHRoZSBkb2N1bWVudHMn ICJjb3BpZXMtY29tcGxldGVkIg0KICAgICB2YWx1ZXMgdGltZXMgdGhlIGpv YidzICJyZXN1bHRzLXByb2ZpbGUuam9iLWNvcGllcyIgdmFsdWUuDQogIDcu IFRoZSBORFBTIEdlbmVyYXRsaXplZFRpbWUgZGF0YSB0eXBlIGlzIGRlZmlu ZWQgYnkgSVNPIDg4MjQNCiAgICAgKElTTy04ODI0KSB3aGlsZSB0aGUgTUlC IERhdGVBbmRUaW1lIGlzIGRlZmluZWQgYnkgU05NUHYyLVRDDQogICAgIChT Tk1QdjItVEMpLg0KDQoNCg0KOC4wICBQUklOVEVSIEpPQiBMQU5HVUFHRSAo UEpMKQ0KDQpQSkwgW1BKTF0gaGFzIGJlZW4gZGV2ZWxvcGVkIGJ5IEhld2xl dHQtUGFja2FyZCB0byBwcm92aWRlIGpvYiBjb250cm9sDQppbmZvcm1hdGlv biB0byB0aGUgcHJpbnRlciBhbmQgc3RhdHVzIGluZm9ybWF0aW9uIHRvIGFw cGxpY2F0aW9ucywNCmluZGVwZW5kZW50IG9mIHRoZSBQREwuDQoNCg0KDQoN Cg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwg ICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMTVdDQwNCklOVEVSTkVULURS QUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAg ICAgIEZlYiAxMCwgMTk5OA0KDQoNCg0KDQo4LjEgIGptSm9iU3VibWlzc2lv bklEIE1hcHBlZCB0byBQSkwNCg0KUEpMIGhhcyBkZWZpbmVkIHRoZSBTVUJN SVNTSU9OSUQgb3B0aW9uIGZvciB0aGUgSk9CIGNvbW1hbmQgd2hpY2gNCmlu ZGljYXRlcyBhIHByb3Blcmx5IGZvcm1hdHRlZCBqbUpvYlN1Ym1pc3Npb25J RCBmb3IgdXNlIGluIHRoZSBKb2IgTUlCLg0KVGhlIFBKTCBKT0IgY29tbWFu ZCBpcyBwcmVzZW50ZWQgYXQgdGhlIHN0YXJ0IG9mIGEgcHJpbnQgam9iIHdp dGgNCm9wdGlvbnMgdGhhdCBhcHBseSBvbmx5IHRoZSBhdHRhY2hlZCBqb2Iu ICBUaGUgc3ludGF4IGZvciB0aGlzIGNvbW1hbmQNCm9wdGlvbiBpczoNCg0K ICAgICAgQFBKTCBKT0IgU1VCTUlTU0lPTklEID0gImlkIHN0cmluZyINCg0K RHJpdmVyIHNvZnR3YXJlIHRoYXQgaW1wbGVtZW50cyB0aGlzIFBKTCBjb21t YW5kIG9wdGlvbiBtdXN0IHByb3ZpZGUgdGhlDQoiaWQgc3RyaW5nIiBpbiBv bmUgb2YgdGhlIGNsaWVudCB2ZXJzaW9uIGZvcm1hdHMgc3BlY2lmaWVkIGlu IHRoZSBKb2INCk1JQiBmb3Igam1Kb2JTdWJtaXNzaW9uSUQuDQoNCkZvciBk cml2ZXJzIHRoYXQgYXJlIG5vdCBhYmxlIHRvIGNyZWF0ZSB0aGUgU1VCTUlT U0lPTklEIG9wdGlvbiwgaXQgaXMNCnJlY29tbWVuZGVkIHRoYXQgam1Kb2JT dWJtaXNzaW9uSUQgZm9ybWF0IDAgYmUgY3JlYXRlZCBieSB0aGUgYWdlbnQN CnVzaW5nIHRoZSBQSkwgYXR0cmlidXRlIERvY093bmVyIG9yIERvY093bmVy SWQuDQoNCiAgb2N0ZXQgMTogICAnMCcNCg0KICBvY3RldHMgMi00MDogIENv bnRhaW5zIHRoZSBzdHJpbmcgYXNzb2NpYXRlZCB3aXRoIERvY093bmVyIG9y DQogICAgICAgICAgICAgICAgRG9jT3duZXJJZC4gIElmIHRoZSBzdHJpbmcg aXMgbGVzcyB0aGFuIDQwIG9jdGV0cywgdGhlDQogICAgICAgICAgICAgICAg bGVmdC1tb3N0IGNoYXJhY3RlciBpbiB0aGUgc3RyaW5nIHNoYWxsIGFwcGVh ciBpbiBvY3RldA0KICAgICAgICAgICAgICAgIHBvc2l0aW9uIDIuICBPdGhl cndpc2UsIG9ubHkgdGhlIGxhc3QgMzkgYnl0ZXMgc2hhbGwgYmUNCiAgICAg ICAgICAgICAgICBpbmNsdWRlZC4gIEFueSB1bnVzZWQgcG9ydGlvbiBvZiB0 aGlzIGZpZWxkIHNoYWxsIGJlDQogICAgICAgICAgICAgICAgZmlsbGVkIHdp dGggc3BhY2VzLiAgSWYgRG9jT3duZXIgb3IgRG9jT3duZXJJZCBjYW5ub3Qg YmUNCiAgICAgICAgICAgICAgICBvYnRhaW5lZCwgdGhpcyBmaWVsZCBzaGFs bCBiZSBibGFuay4NCg0KICBvY3RldHMgNDEtNDg6ICBDb250YWlucyB0aGUg dmFsdWUgb2Ygam1Kb2JJbmRleCBhc3NvY2lhdGVkIHdpdGggdGhlDQogICAg ICAgICAgICAgICAgIGpvYi4gIExlYWRpbmcgemVyb3Mgc2hhbGwgYmUgaW5z ZXJ0ZWQgdG8gZmlsbCB0aGUNCiAgICAgICAgICAgICAgICAgZW50aXJlIDgg b2N0ZXQgZmllbGQuDQoNCg0KOC4yICBqbUpvYkluZGV4IE1hcHBlZCB0byBQ SkwNCg0KUEpMIGRvZXMgbm90IHByb3ZpZGUgYSB2YWx1ZSB0aGF0IGNhbiBi ZSBtYXBwZWQgdG8gam1Kb2JJbmRleC4NCg0KDQo4LjMgIE90aGVyIE1JQiBP YmplY3RzIE1hcHBlZCB0byBQSkwNCg0KTUlCIE9iamVjdCAgICAgICAgICAg IHwgUEpMIEpvYiBhdHRyaWJ1dGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpqb2JPd25l ciAgICAgICAgICAgICAgfCBEb2NPd25lciBvciBEb2NPd25lcklkIGF0dHJp YnV0ZQ0KDQoNCjguNCAgVGhlIEF0dHJpYnV0ZSBHcm91cCBNYXBwZWQgdG8g UEpMDQoNClRoZSBmb2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlm IHRoZSBsaXN0ZWQgUEpMIGF0dHJpYnV0ZSBvcg0KY29tbWFuZCBvcHRpb24g aXMgcHJvdmlkZWQuDQoNCg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAg ICAgICAgICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBb cGFnZSAxNl0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Np b24gUHJvdG9jb2wgTWFwcGluZyAgICAgICAgRmViIDEwLCAxOTk4DQoNCg0K DQoNCk1JQiBhdHRyaWJ1dGUgICAgICAgICB8IFBKTCBhdHRyaWJ1dGUgb3Ig Y29tbWFuZCBvcHRpb24gIHwgRGF0YSB0eXBlDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0NCnNlcnZlckFzc2lnbmVkSm9iTmFtZSB8IERvY05hbWUg YXR0cmlidXRlIG9yIHRoZSBjb21tYW5kIHwgT2N0ZXQgU3RyaW5nDQogICAg ICAgICAgICAgICAgICAgICAgfCAgQFBKTCBKT0IgTmFtZSA9ICJzdHJpbmci ICAgICAgICB8IE9jdGV0IFN0cmluZw0Kc3VibWl0dGluZ1NlcnZlck5hbWUg IHwgU3JjU2VydmVyTmFtZSBhdHRyaWJ1dGUgICAgICAgICAgfCBPY3RldCBT dHJpbmcNCmpvYk9yaWdpbmF0aW5nSG9zdCAgICB8IFNyY1BvcnQgYXR0cmli dXRlICAgICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpxdWV1ZU5hbWVS ZXF1ZXN0ZWQgICAgfCBTcmNRIGF0dHJpYnV0ZSAgICAgICAgICAgICAgICAg ICB8IE9jdGV0IFN0cmluZw0KZmlsZU5hbWUgICAgICAgICAgICAgIHwgSm9i Rk5hbWUgYXR0cmlidXRlICAgICAgICAgICAgICAgfCBPY3RldCBTdHJpbmcN CmpvYkNvbW1lbnQgICAgICAgICAgICB8IEpvYkRlc2MgYXR0cmlidXRlICAg ICAgICAgICAgICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdWJtaXNzaW9uVGlt ZSAgICAgfCBUaW1lU3VibWl0IGF0dHJpYnV0ZSAgICAgICAgICAgICB8IE9j dGV0IFN0cmluZw0KDQoNCg0KOS4wICBQT1NUU0NSSVBUDQoNClRoZSBQb3N0 U2NyaXB0IFBETCBwZXJtaXRzIGNvbW1lbnQgZmllbGRzIHdoaWNoIGNhbiBi ZSB1c2VkIGJ5DQphcHBsaWNhdGlvbiBkcml2ZXJzIHRvIGluY2x1ZGUgam9i IGluZm9ybWF0aW9uLiAgQWx0aG91Z2ggdGhlcmUgYXJlIG5vDQpyZXN0cmlj dGlvbnMgb3IgcmVxdWlyZW1lbnRzIGFzIHRvIHdoYXQgaW5mb3JtYXRpb24g bWF5IGJlIGluY2x1ZGVkLA0KbWFueSBkcml2ZXJzIGluY2x1ZGUgam9iIG93 bmVyIGFuZC9vciBkb2N1bWVudCBuYW1lLg0KDQoNCjkuMSAgam1Kb2JTdWJt aXNzaW9uSUQgTWFwcGVkIHRvIFBvc3RTY3JpcHQNCg0KVGhlIHVzZSBvZiBh IHN0YW5kYXJkIGZvcm1hdCBqb2Igc3VibWlzc2lvbiBpZCBjb21tZW50IHN0 cmluZyB3aWxsIGFsbG93DQppbnRlcm9wZXJhYmlsaXR5IG9mIHByaW50ZXJz IGFuZCBkcml2ZXJzIGZyb20gbXVsdGlwbGUgdmVuZG9ycy4gIFRoZQ0KZm9s bG93aW5nIGNvbW1lbnQgc3RyaW5nIGZvcm1hdCBpcyByZWNvbW1lbmRlZCBm b3IgdXNlIHdpdGggUG9zdFNjcmlwdA0KbGV2ZWwgMSBhbmQgbGV2ZWwgMiBk YXRhIHN0cmVhbXMuDQoNCiAgICAgJSVKTVBKb2JTdWJtaXNzaW9uSWQ6KGlk LXN0cmluZykNCg0Kd2hlcmUgImlkIHN0cmluZyIgY2FuIGJlIGFueSBqbUpv YlN1Ym1pc3Npb25JRCBmb3JtYXQgcmVzZXJ2ZWQgZm9yDQpjbGllbnRzLg0K DQo5LjIgIE90aGVyIE1JQiBPYmplY3RzIGFuZCBBdHRyaWJ1dGVzIE1hcHBl ZCB0byBQb3N0U2NyaXB0DQoNCk5vIE90aGVyIG1hcHBpbmdzIGZyb20gUG9z dFNjcmlwdCBjb21tZW50IHN0cmluZ3MgYXJlIHJlY29tbWVuZGVkLCBidXQN Cm1hbnkgSm9iIE1JQiBvYmplY3RzIGFuZCBhdHRyaWJ1dGVzIGNhbiBiZSBk ZWZpbmVkIHVzaW5nIHZlbmRvciB1bmlxdWUNCmNvbW1lbnQgc3RyaW5ncy4N Cg0KDQoNCjEwLjAgIE5FVFdBUkUgUFNFUlZFUg0KDQpUaGUgTmV0V2FyZSBQ U2VydmVyIGpvYiBzdWJtaXNzaW9uIHByb3RvY29sIGlzIGltcGxlbWVudGVk IGluIGEgY2xpZW50LQ0Kc2VydmVyLXByaW50ZXIgc3lzdGVtIG9uIHRoZSBz ZXJ2ZXIgdG8gcHJpbnRlciBsaW5rIGFzIGRlZmluZWQgaW4NCmNvbmZpZ3Vy YXRpb24gMy4NCg0KDQoxMC4xICBqbUpvYlN1Ym1pc3Npb25JRCBNYXBwZWQg dG8gUFNlcnZlcg0KDQogIG9jdGV0IDE6ICAgJ0InDQoNCg0KDQoNCkJlcmdt YW4gICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAg ICAgICAgICAgICAgIFtwYWdlIDE3XQ0MDQpJTlRFUk5FVC1EUkFGVCAgICAg ICBKb2IgU3VibWlzc2lvbiBQcm90b2NvbCBNYXBwaW5nICAgICAgICBGZWIg MTAsIDE5OTgNCg0KDQoNCg0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMg dGhlIERpcmVjdG9yeSBQYXRoIE5hbWUgb2YgdGhlIGFnZW50IGFzDQogICAg ICAgICAgICAgICAgcmVjb3JkZWQgYnkgdGhlIE5vdmVsbCBGaWxlIFNlcnZl ciBpbiB0aGUgcXVldWUNCiAgICAgICAgICAgICAgICBkaXJlY3RvcnkuICBJ ZiB0aGUgc3RyaW5nIGlzIGxlc3MgdGhhbiA0MCBvY3RldHMsIHRoZQ0KICAg ICAgICAgICAgICAgIGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmlu ZyBzaGFsbCBhcHBlYXIgaW4gb2N0ZXQNCiAgICAgICAgICAgICAgICBwb3Np dGlvbiAyLiAgT3RoZXJ3aXNlLCBvbmx5IHRoZSBsYXN0IDM5IGJ5dGVzIHNo YWxsIGJlDQogICAgICAgICAgICAgICAgaW5jbHVkZWQuICBBbnkgdW51c2Vk IHBvcnRpb24gb2YgdGhpcyBmaWVsZCBzaGFsbCBiZQ0KICAgICAgICAgICAg ICAgIGZpbGxlZCB3aXRoIHNwYWNlcy4NCg0KICBvY3RldHMgNDEtNDg6ICAn MDAwWFhYWFgnICBUaGUgZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2Vu dGF0aW9uIG9mDQogICAgICAgICAgICAgICAgIHRoZSBKb2IgTnVtYmVyIGFz IHBlciB0aGUgTmV0V2FyZSBGaWxlIFNlcnZlciBRdWV1ZQ0KICAgICAgICAg ICAgICAgICBNYW5hZ2VtZW50IFNlcnZpY2VzLg0KDQoNCjEwLjIgIGptSm9i SW5kZXggTWFwcGVkIHRvIFBTZXJ2ZXINCg0KVGhlIGpvYiBpbmRleCAoam1K b2JJbmRleCkgaXMgYXNzaWduZWQgYnkgdGhlIFNOTVAgam9iIG1vbml0b3Jp bmcgYWdlbnQNCmFuZCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgSm9iIE51bWJl ciBhc3NpZ25lZCBieSB0aGUgTmV0V2FyZSBGaWxlIFNlcnZlcg0KUXVldWUg TWFuYWdlbWVudCBTZXJ2aWNlcy4gIFRoaXMgd2lsbCBhbGxvdyB0aGUgU05N UCBhZ2VudCB0byB0cmFjayBqb2JzDQpyZWNlaXZlZCBmcm9tIG11bHRpcGxl IHNvdXJjZXMuDQoNCg0KMTAuMyAgT3RoZXIgTUlCIE9iamVjdHMgTWFwcGVk IHRvIFBKTA0KDQpNSUIgT2JqZWN0ICAgICAgICAgICAgfCBQU2VydmVyIEpv YiBhdHRyaWJ1dGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmpvYk93bmVy ICAgICAgICAgICAgICB8IENsaWVudCBJZCBOdW1iZXINCg0KDQoxMC40ICBU aGUgQXR0cmlidXRlIEdyb3VwIE1hcHBlZCB0byBQU2VydmVyDQoNClRoZSBm b2xsb3dpbmcgbWFwcGluZ3MgYXJlIHJlcXVpcmVkIGlmIHRoZSBsaXN0ZWQg UFNlcnZlciBwYXJhbWV0ZXIgaXMNCnByb3ZpZGVkIGluIHRoZSBOb3ZlbGwg RmlsZSBTZXJ2ZXIgcXVldWUgZGlyZWN0b3J5Lg0KDQpNSUIgYXR0cmlidXRl ICAgICAgICAgICAgICB8IFBTZXJ2ZXIgcGFyYW1ldGVyICAgICAgICAgICB8 IERhdGEgdHlwZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tDQpzZXJ2 ZXJBc3NpZ25lZEpvYk5hbWUgICAgICB8IEpvYiBGaWxlIE5hbWUgICAgICAg ICAgICAgICB8IE9jdGV0IFN0cmluZw0KcXVldWVOYW1lUmVxdWVzdGVkICAg ICAgICAgfCBRdWV1ZSBJZCAgICAgICAgICAgICAgICAgICAgfCBJbnRlZ2Vy DQpwaHlzaWNhbERldmljZSAgICAgICAgICAgICB8IFNlcnZlciBJZCBOdW1i ZXIgICAgICAgICAgICB8IEludGVnZXINCmpvYkNvbW1lbnQgICAgICAgICAg ICAgICAgIHwgSm9iIERlc2NyaXB0aW9uICAgICAgICAgICAgIHwgT2N0ZXQg U3RyaW5nDQpqb2JQcmlvcml0eSAgICAgICAgICAgICAgICB8IChub3RlIDEp ICAgICAgICAgICAgICAgICAgICB8IEludGVnZXINCmpvYlByb2Nlc3NBZnRl ckRhdGVBbmRUaW1lIHwgVGFyZ2V0IEV4ZWN1dGlvbiBUaW1lICAgICAgIHwg T2N0ZXQgU3RyaW5nDQpqb2JDb3BpZXNSZXF1ZXN0ZWQgICAgICAgICB8IE51 bWJlciBvZiBDb3BpZXMgICAgICAgICAgICB8IEludGVnZXINCm1lZGl1bVJl cXVlc3RlZCAgICAgICAgICAgIHwgRm9ybSBOYW1lICAgICAgICAgICAgICAg ICAgIHwgT2N0ZXQgU3RyaW5nDQpqb2JTdWJtaXNzaW9uVG9TZXJ2ZXJUaW1l ICB8IEpvYiBFbnRyeSBUaW1lICAgICAgICAgICAgICB8IE9jdGV0IFN0cmlu Zw0KDQpOb3RlczoNCi0tLS0tLQ0KIDEuIFRoZSBqb2IgcHJpb3JpdHkgaXMg ZGV0ZXJtaW5lZCBieSB0aGUgcHJpb3JpdHkgYXNzaWduZWQgdG8gdGhlIHF1 ZXVlDQogICAgdGhhdCBjb250YWlucyB0aGUgam9iLiAgRWFjaCBxdWV1ZSBj YW4gYmUgYXNzaWduZWQgYSB1bmlxdWUgcHJpb3JpdHkNCiAgICBhbmQgdGhl IHByaW9yaXR5IG9mIHRoZSBqb2IgaXMgaW5oZXJpdGVkIGZyb20gdGhlIHF1 ZXVlLg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5m b3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAxOF0NDA0K SU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wg TWFwcGluZyAgICAgICAgRmViIDEwLCAxOTk4DQoNCg0KDQoNCg0KDQoxMS4w ICBORVRXQVJFIE5QUklOVEVSIG9yIFJQUklOVEVSDQoNClRoZSBOZXRXYXJl IE5QcmludGVyL1JQcmludGVyIHByb3RvY29sIHdhcyBkZXNpZ25lZCB0byB0 cmFuc2ZlciBwcmludA0KZGF0YSBmcm9tIGEgTm92ZWxsIEZpbGUgU2VydmVy IHRvIGEgcHJpbnRlciBhdHRhY2hlZCBkaXJlY3RseSB0byBhIGxvY2FsDQpw b3J0IChlLmcuIHBhcmFsbGVsIG9yIHNlcmlhbCkgb24gYSBQQy4gIE5Qcmlu dGVyL1JQcmludGVyIGlzIGFuDQpleHRyZW1lbHkgbGlnaHR3ZWlnaHQgcHJp bnRpbmcgcHJvdG9jb2wuICBDb25zZXF1ZW50bHksIG5vIGluZm9ybWF0aW9u DQpyZXF1aXJlZCBieSB0aGUgSm9iIE1vbml0b3JpbmcgTUlCIGlzIHByb3Zp ZGVkIGFuZCBhIG1lYW5pbmdmdWwNCmptSm9iU3VibWlzc2lvbklEIGNhbm5v dCBiZSBnZW5lcmF0ZWQuDQoNCkl0IGlzIHJlY29tbWVuZGVkIHRoYXQgYW4g YWRkaXRpb25hbCBqb2Igc3VibWlzc2lvbiBsYXllciwgc3VjaCBhcyBQSkwN Cm9yIGFub3RoZXIgdmVuZG9yIHByaXZhdGUgcHJvdG9jb2wsICBiZSBpbmNs dWRlZCBvbiB0b3Agb2YNCk5QcmludGVyL1JQcmludGVyIHRvIHByb3ZpZGUg dGhlIHJlcXVpcmVkIGluZm9ybWF0aW9uLiAgVGhlIG1hcHBpbmcNCnNob3Vs ZCB0aGVuIGJlIHBlcmZvcm1lZCBhY2NvcmRpbmcgdG8gdGhlIHJlY29tbWVu ZGF0aW9ucyBvZiB0aGUgaGlnaGVyDQpsYXllciBzdWJtaXNzaW9uIHByb3Rv Y29sLg0KDQoNCg0KMTIuMCAgU0VSVkVSIE1FU1NBR0UgQkxPQ0sgKFNNQikg UFJPVE9DT0wNCg0KVGhlIFNlcnZlciBNZXNzYWdlIEJsb2NrIHByb3RvY29s IGlzIHVzZWQgd2l0aCBzZXZlcmFsIFBDIE5ldHdvcmsNCm9wZXJhdGluZyBz eXN0ZW1zLCBzdWNoIGFzIE1pY3Jvc29mdCBXaW5kb3dzIGZvciBXb3JrZ3Jv dXBzLCBJQk0gTEFODQpTZXJ2ZXIsIGFuZCBBcnRpc29mdCBMYW50YXN0aWMu ICBTTUIgc3lzdGVtcyBzdXBwb3J0aW5nIHRoZSBKb2INCk1vbml0b3Jpbmcg TUlCIHdpbGwgY29uZm9ybSB0byBlaXRoZXIgY29uZmlndXJhdGlvbiAxIG9y IDMuDQoNCg0KMTIuMSAgam1Kb2JTdWJtaXNzaW9uSUQgTWFwcGVkIHRvIFNN Qg0KDQogIG9jdGV0IDE6ICAgJ0MnDQoNCiAgb2N0ZXRzIDItNDA6ICBDb250 YWlucyBhIGRlY2ltYWwgKEFTQ0lJIGNvZGVkKSByZXByZXNlbnRhdGlvbiBv ZiB0aGUNCiAgICAgICAgICAgICAgICAxNiBiaXQgU01CIFRyZWUgSWQgZmll bGQsIHdoaWNoIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlDQogICAgICAgICAg ICAgICAgY29ubmVjdGlvbiB0aGF0IHN1Ym1pdHRlZCB0aGUgam9iIHRvIHRo ZSBwcmludGVyLiAgVGhlDQogICAgICAgICAgICAgICAgbW9zdCBzaWduaWZp Y2FudCBkaWdpdCBvZiB0aGUgbnVtZXJpYyBzdHJpbmcgc2hhbGwgYmUNCiAg ICAgICAgICAgICAgICBwbGFjZWQgaW4gb2N0ZXQgcG9zaXRpb24gMi4gIEFs bCB1bnVzZWQgcG9ydGlvbnMgb2YgdGhpcw0KICAgICAgICAgICAgICAgIGZp ZWxkIHNoYWxsIGJlIGZpbGxlZCB3aXRoIHNwYWNlcy4gIFRoZSBTTUIgVHJl ZSBJZCBoYXMNCiAgICAgICAgICAgICAgICBhIG1heGltdW0gdmFsdWUgb2Yg NjUsNTM1Lg0KDQogIG9jdGV0cyA0MS00ODogIENvbnRhaW5zIGEgZGVjaW1h bCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0KICAgICAg ICAgICAgICAgICBGaWxlIEhhbmRsZSByZXR1cm5lZCBmcm9tIHRoZSBwcmlu dGVyIGFnZW50IHRvIHRoZQ0KICAgICAgICAgICAgICAgICBjbGllbnQgaW4g cmVzcG9uc2UgdG8gYSBDcmVhdGUgUHJpbnQgRmlsZSBjb21tYW5kLg0KICAg ICAgICAgICAgICAgICBMZWFkaW5nIHplcm9zIHNoYWxsIGJlIGluc2VydGVk IHRvIGZpbGwgdGhlIGVudGlyZSA4DQogICAgICAgICAgICAgICAgIG9jdGV0 IGZpZWxkLg0KDQoNCjEyLjIgIGptSm9iSW5kZXggTWFwcGVkIHRvIFNNQg0K DQpJdCBpcyBzdHJvbmdseSByZWNvbW1lbmRlZCB0aGF0IHRoZSBGaWxlIEhh bmRsZSByZXR1cm5lZCBmcm9tIHRoZQ0KcHJpbnRlciBhZ2VudCBiZSBpZGVu dGljYWwgdG8gam1Kb2JJbmRleC4gIElmIHRoZXNlIGl0ZW1zIGFyZSBpZGVu dGljYWwsDQp0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgY2xpZW50IGFwcGxp Y2F0aW9uIHRvIHBlcmZvcm0gYSBzZWFyY2ggb24NCg0KDQoNCg0KQmVyZ21h biAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uYWwgICAgICAgICAg ICAgICAgICAgICAgW3BhZ2UgMTldDQwNCklOVEVSTkVULURSQUZUICAgICAg IEpvYiBTdWJtaXNzaW9uIFByb3RvY29sIE1hcHBpbmcgICAgICAgIEZlYiAx MCwgMTk5OA0KDQoNCg0KDQpqbUpvYlN1Ym1pc3Npb25JRC4gIFRvIGJlIGNv bXBhdGlibGUgd2l0aCB0aGUgMTYgYml0IGZpZWxkIGFsbG9jYXRlZCB0bw0K dGhpcyB2YWx1ZSBieSBTTUIsIHRoZSBtYXhpbXVtIGptSm9iSW5kZXggaXMg NjUsNTM1Lg0KDQoNCjEyLjMgIE90aGVyIE1JQiBvYmplY3RzIE1hcHBlZCB0 byBTTUINCg0KTUlCIE9iamVjdCAgICAgIHwgU01CIFBhcmFtZXRlcg0KLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCmptSm9iT3duZXIgICAgICB8IFNNQiBVc2Vy IElkIGZpZWxkIChub3RlIDEpDQoNCk5vdGVzOg0KLS0tLS0tDQogMS4gQSBk ZWNpbWFsIChBU0NJSSBjb2RlZCkgcmVwcmVzZW50YXRpb24gb2YgdGhlIFNN QiBVc2VyIElkIG51bWVyaWMNCiAgICBzaGFsbCBiZSBwcmVzZW50ZWQgYXMg am1Kb2JPd25lci4NCg0KDQoNCjEzLjAgIFRSQU5TUE9SVCBJTkRFUEVOREVO VCBQUklOVEVSL1NZU1RFTSBJTlRFUkZBQ0UgKFRJUC9TSSkNCg0KVGhlIFRJ UC9TSSBwcm90b2NvbCwgYWx0aG91Z2ggY3VycmVudGx5IHNwZWNpZmllZCBh cyBhIHBhcnQgb2YgdGhlIElFRUUNCjEyODQgcGFyYWxsZWwgcG9ydCBzdGFu ZGFyZHMgW1RJUC9TSV0sIHdhcyBvcmlnaW5hbGx5IGRldmVsb3BlZCBhcyBh DQpuZXR3b3JrIHByb3RvY29sLiAgVElQL1NJIHRodXMgaGFzIHRoZSBwb3Rl bnRpYWwgb2YgYmVpbmcgaW50ZWdyYXRlZA0KaW50byBhbnkgbmV0d29yayBv ciBub24tbmV0d29yayBjb25maWd1cmF0aW9uLg0KDQoNCjEzLjEgIGptSm9i U3VibWlzc2lvbklEIE1hcHBlZCB0byBUSVAvU0kNCg0KICBvY3RldCAxOiAg ICdEJw0KDQogIG9jdGV0cyAyLTQwOiAgQ29udGFpbnMgdGhlIEpvYiBOYW1l IGZyb20gdGhlIEpvYiBDb250cm9sLVN0YXJ0IEpvYg0KICAgICAgICAgICAg ICAgIChKQy1TSikgY29tbWFuZC4gIElmIHRoZSBKb2IgTmFtZSBwb3J0aW9u IGlzIGxlc3MgdGhhbg0KICAgICAgICAgICAgICAgIDQwIG9jdGV0cywgdGhl IGxlZnQtbW9zdCBjaGFyYWN0ZXIgaW4gdGhlIHN0cmluZyBzaGFsbA0KICAg ICAgICAgICAgICAgIGFwcGVhciBpbiBvY3RldCBwb3NpdGlvbiAyLiAgQW55 IHVudXNlZCBwb3J0aW9uIG9mIHRoaXMNCiAgICAgICAgICAgICAgICBmaWVs ZCBzaGFsbCBiZSBmaWxsZWQgd2l0aCBzcGFjZXMuICBPdGhlcndpc2UsIG9u bHkgdGhlDQogICAgICAgICAgICAgICAgbGFzdCAzOSBieXRlcyBzaGFsbCBi ZSBpbmNsdWRlZC4NCg0KDQogIG9jdGV0cyA0MS00ODogIENvbnRhaW5zIGEg ZGVjaW1hbCAoQVNDSUkgY29kZWQpIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0K ICAgICAgICAgICAgICAgICBqbUpvYkluZGV4IGFzc2lnbmVkIGJ5IHRoZSBh Z2VudC4gIExlYWRpbmcgemVyb3Mgc2hhbGwNCiAgICAgICAgICAgICAgICAg YmUgaW5zZXJ0ZWQgdG8gZmlsbCB0aGUgZW50aXJlIDggb2N0ZXQgZmllbGQu DQoNCg0KMTMuMiAgam1Kb2JJbmRleCBNYXBwZWQgdG8gVElQL1NJDQoNCmpt Sm9iSW5kZXggaXMgcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBhcyB0aGUgUHJp bnRlciBBc3NpZ25lZCBKb2IgSWQgaW4gYQ0KSm9iIENvbnRyb2wtU3RhcnQg Sm9iIChKQy1TSikgcmVzcG9uc2UgcGFja2V0LiAgVG8gYmUgY29tcGF0aWJs ZSB3aXRoDQp0aGUgMTYgYml0IGZpZWxkIGFsbG9jYXRlZCB0byB0aGlzIHZh bHVlIGJ5IFRJUC9TSSwgdGhlIG1heGltdW0NCmptSm9iSW5kZXggaXMgNjUs NTM1Lg0KDQoNCg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAg ICAgSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAy MF0NDA0KSU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJv dG9jb2wgTWFwcGluZyAgICAgICAgRmViIDEwLCAxOTk4DQoNCg0KDQoNCjEz LjMgIE90aGVyIE1JQiBPYmplY3RzIE1hcHBlZCB0byBUSVAvU0kNCg0KTUlC IE9iamVjdCAgICAgICAgICAgICB8IFRJUC9TSSBQYXJhbWV0ZXINCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kam1Kb2JPd25lciAgICAgICAgICAg ICB8IFVzZXIgc3RyaW5nDQoNCg0KMTMuNCAgVGhlIEF0dHJpYnV0ZSBHcm91 cCBNYXBwZWQgdG8gVElQL1NJDQoNCk1JQiBhdHRyaWJ1dGUgICAgICAgICB8 IFRJUC9TSSBpbmZvcm1hdGlvbiAgICAgICAgICAgICAgfCBEYXRhIHR5cGUN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tDQpqb2JOYW1lICAgICAgICAg ICAgICAgfCBKb2IgTmFtZSBzdHJpbmcgICAgICAgICAgICAgICAgIHwgT2N0 ZXQgU3RyaW5nDQpqb2JDb21tZW50ICAgICAgICAgICAgfCBBZGRpdGlvbmFs IEluZm9ybWF0aW9uIHN0cmluZyAgIHwgT2N0ZXQgU3RyaW5nDQoNCg0KDQox NC4wICBSRUZFUkVOQ0VTDQoNCltEUEFdICBJU08vSUVDIDEwMTc1LTE6MTk5 NihFKSwgIkluZm9ybWF0aW9uIHRlY2hub2xvZ3kgLSBUZXh0IGFuZA0Kb2Zm aWNlIHN5c3RlbXMgLSBEb2N1bWVudCBQcmludGluZyBBcHBsaWNhdGlvbiAo RFBBKSAtIFBhcnQgMTogQWJzdHJhY3QNCnNlcnZpY2UgZGVmaW5pdGlvbiBh bmQgcHJvY2VkdXJlcyIsIEpUQzEvU0MxOC4NCg0KW0lQUF0gIFRoZSBJbnRl cm5ldCBQcmludGluZyBQcm90b2NvbCBSRkMgWFhYWCwgTW9kZWwgUkZDIFhY WFgNCg0KW0lTTy04ODI0XSAgSVNPL0lFQyA4ODI0OjE5OTAsICJJbmZvcm1h dGlvbiB0ZWNobm9sb2d5IC0gT3BlbiBTeXN0ZW1zDQpJbnRlcmNvbm5lY3Rp b24gLSBTcGVjaWZpY2F0aW9uIG9mIEFic3RyYWN0IFN5bnRheCBOb3RhdGlv biAoQVNOLjEpIi4NCg0KW0pvYk1JQl0gIFRoZSBKb2IgTW9uaXRvcmluZyBN SUIsIHdvcmsgaW4gcHJvZ3Jlc3MsIDxkcmFmdC1pZXRmLQ0KcHJpbnRtaWIt am9iLW1vbml0b3JpbmctMDcudHh0PiwgdG8gYmUgcHVibGlzaGVkIGFzIGFu IEluZm9ybWF0aW9uYWwgUkZDDQphcyBhIFByaW50ZXIgV29ya2luZyBHcm91 cCAoUFdHKSBzdGFuZGFyZC4NCg0KW0xQRF0gIExpbmUgUHJpbnRlciBEYWVt b24gUHJvdG9jb2wsIFJGQyAxMTc5LCBJRVRGIGluZm9ybWF0aW9uYWwNCmRv Y3VtZW50Lg0KDQpbUEpMXSAgUHJpbnRlciBKb2IgTGFuZ3VhZ2UgVGVjaG5p Y2FsIFJlZmVyZW5jZSBNYW51YWwsIEhld2xldHQtUGFja2FyZA0KcGFydCBu dW1iZXIgNTAyMS0wMzI4Lg0KDQpbUHJ0TUlCXSAgVGhlIFByaW50ZXIgTUlC LCBSRkMgMTc1OSwgSUVURiBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQuDQoN CltTTk1QdjItVENdICBDYXNlLCBKLiwgTWNDbG9naHJpZSwgSy4sIFJvc2Us IE0uLCBXYWxkYnVzc2VyLCBTLiwNCiJUZXh0dWFsIENvbnZlbnRpb25zIGZv ciBWZXJzaW9uIDIgb2YgdGhlIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQN ClByb3RvY29sIChTTk1QdjIpLCBSRkMgMTkwMywgSmFudWFyeSAxOTk2Lg0K DQpbVElQL1NJXSAgSUVFRSBTdGFuZGFyZCAxMjg0LjEsIFRyYW5zcG9ydCBJ bmRlcGVuZGVudCBQcmludGVyL1N5c3RlbQ0KSW50ZXJmYWNlLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpCZXJnbWFuICAgICAgICAgICAgICAgICAgICAgSW5m b3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICBbcGFnZSAyMV0NDA0K SU5URVJORVQtRFJBRlQgICAgICAgSm9iIFN1Ym1pc3Npb24gUHJvdG9jb2wg TWFwcGluZyAgICAgICAgRmViIDEwLCAxOTk4DQoNCg0KDQoNCjE1LjAgIEFV VEhPUlMNCg0KVGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCB3aXRoIHNpZ25p ZmljYW50IGNvbnRyaWJ1dGlvbnMgZnJvbSB0aGUNCmZvbGxvd2luZyBpbmRp dmlkdWFscy4NCg0KICAgIFJvbiBCZXJnbWFuIChFZGl0b3IpDQogICAgRGF0 YXByb2R1Y3RzIENvcnAuDQogICAgMTc1NyBUYXBvIENhbnlvbiBSb2FkDQog ICAgU2ltaSBWYWxsZXksIENBIDkzMDYzLTMzOTQNCg0KICAgIFBob25lOiA4 MDUtNTc4LTQ0MjENCiAgICBGYXg6ICA4MDUtNTc4LTQwMDENCiAgICBFbWFp bDogcmJlcmdtYW5AZHBjLmNvbQ0KDQoNCiAgICBUb20gSGFzdGluZ3MNCiAg ICBYZXJveCBDb3Jwb3JhdGlvbiwgRVNBRS0yMzENCiAgICA3MDEgUy4gQXZp YXRpb24gQmx2ZC4NCiAgICBFbCBTZWd1bmRvLCBDQSAgIDkwMjQ1DQoNCiAg ICBQaG9uZTogMzEwLTMzMy02NDEzDQogICAgRmF4OiAgIDMxMC0zMzMtNTUx NA0KICAgIEVNYWlsOiBoYXN0aW5nc0BjcDEwLmVzLnhlcm94LmNvbQ0KDQoN CiAgICBTY290dCBBLiBJc2FhY3Nvbg0KICAgIE5vdmVsbCwgSW5jLg0KICAg IDEyMiBFIDE3MDAgUw0KICAgIFByb3ZvLCBVVCAgIDg0NjA2DQoNCiAgICBQ aG9uZTogODAxLTg2MS03MzY2DQogICAgRmF4OiAgIDgwMS04NjEtNDAyNQ0K ICAgIEVNYWlsOiBzY290dF9pc2FhY3NvbkBub3ZlbGwuY29tDQoNCg0KICAg IEhhcnJ5IExld2lzDQogICAgSUJNIENvcnBvcmF0aW9uDQogICAgNjMwMCBE aWFnb25hbCBId3kNCiAgICBCb3VsZGVyLCBDTyA4MDMwMQ0KDQogICAgUGhv bmU6ICgzMDMpIDkyNC01MzM3DQogICAgRmF4OiAgICgzMDMpIDkyNC00NjYy DQogICAgRW1haWw6IGhhcnJ5bEB1cy5pYm0uY29tDQoNCg0KICAgIEJvYiBQ ZW50ZWNvc3QNCiAgICBIZXdsZXR0LVBhY2thcmQgQ29ycG9yYXRpb24NCiAg ICAxMTMxMSBDaGluZGVuIEJvdWxldmFyZA0KICAgIEJvaXNlLCBJRCA4Mzcx NA0KDQoNCg0KDQoNCg0KQmVyZ21hbiAgICAgICAgICAgICAgICAgICAgIElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMjJdDQwN CklOVEVSTkVULURSQUZUICAgICAgIEpvYiBTdWJtaXNzaW9uIFByb3RvY29s IE1hcHBpbmcgICAgICAgIEZlYiAxMCwgMTk5OA0KDQoNCg0KDQogICAgUGhv bmU6ICgyMDgpIDM5Ni0zMzEyDQogICAgRmF4OiAgICgyMDgpIDM5Ni00MTIy DQogICAgRW1haWw6IGJwZW50ZWNvQGJvaS5ocC5jb20NCg0KDQogICAgU2Vu ZCBjb21tZW50cyB0byB0aGUgcHJpbnRtaWIgV0cgdXNpbmcgdGhlIEpvYiBN b25pdG9yaW5nIFByb2plY3QNCiAgICAoSk1QKSBNYWlsaW5nIExpc3Q6ICBq bXBAcHdnLm9yZw0KDQogICAgRm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24sIGFj Y2VzcyB0aGUgUFdHIHdlYiBwYWdlIHVuZGVyICJKTVAiOg0KICAgIGh0dHA6 Ly93d3cucHdnLm9yZy8NCg0KDQpPdGhlciBQYXJ0aWNpcGFudHM6DQoNCiAg ICBDaHVjayBBZGFtcyAtIFRla3Ryb25peA0KICAgIEtlaXRoIENhcnRlciAt IElCTSBDb3Jwb3JhdGlvbg0KICAgIEFuZ2VsbyBDYXJ1c28gLSBYZXJveA0K ICAgIEplZmYgQ29wZWxhbmQgLSBRTVMNCiAgICBBbmR5IERhdmlkc29uIC0g VGVrdHJvbml4DQogICAgTWFicnkgRG96aWVyIC0gUU1TDQogICAgTGVlIEZl cnJlbCAtIENhbm9uDQogICAgRGF2aWQgS2VsbGVybWFuIC0gTm9ydGhsYWtl IFNvZnR3YXJlDQogICAgUmljayBMYW5kYXUgLSBEaWdpdGFsDQogICAgSmF5 IE1hcnRpbiAtIFVuZGVyc2NvcmUNCiAgICBJcmEgTWNEb25hbGQgLSBYZXJv eA0KICAgIFN0dWFydCBSb3dsZXkgLSBLeW9jZXJhDQogICAgQm9iIFNldHRl cmJvIC0gQWRvYmUNCiAgICBHYWlsIFNvbmdlciAtIEVGSQ0KICAgIE1pa2Ug VGltcGVybWFuIC0gTGV4bWFyaw0KICAgIFdpbGxpYW0gV2FnbmVyIC0gRFBJ L09zaWNvbQ0KICAgIENocmlzIFdlbGxlbnMgLSBJbnRlcndvcmtpbmcgTGFi cw0KICAgIFJvYiBXaGl0dGxlIC0gTm92ZWxsDQogICAgRG9uIFdyaWdodCAt IExleG1hcmsNCiAgICBMbG95ZCBZb3VuZyAtIExleG1hcmsNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkJlcmdtYW4gICAg ICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAg ICAgICAgIFtwYWdlIDIzXQ0MDQoNCg== From rbergma at dpc.com Wed Feb 11 11:34:27 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> Version 3 submitted to the IETF Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> I have submitted the latest version of the Job Submission Protocol Mapping Recommendations to the IETF this morning. The file name will be: draft-ietf-printmib-job-protomap-03.txt Whatch for the announcement of its posting. I have also archived the files on the PWG server at: ftp://ftp.pwg.org/pub/pwg/jmp/specs/JMPMAP10.DOC (.TXT) Since the "final" version of the Job MIB has already been posted, as soon as the posting of the Mapping document is announced, I will request that the IESG consider these document to be released as Informational RFCs. I expect the Mapping document to be posted tomorrow, so if you have any comments on either document they must be made known immediately. Ron Bergman Dataproducts Corp. From carterk at us.ibm.com Wed Feb 11 17:35:45 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> PWG meeting in Austin on 3/2-6 Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> Print gurus, Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6. I've sent the information to the Hyatt hotel. You may start making your hotel reservations under "Printer Working Group" on Thursday, 2/12. The phone number for the Hyatt hotel is 512-477-1234. Reservations at the IBM rate of $101/night rate will be accepted through Tuesday, 2/17. If you make your reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't procrastinate. If you have already made your reservation, please contact the hotel on 2/12 and inform them you are with the "Printer Working Group" to get the IBM rate (several of you informed me that you already made your reservations so I forwarded this information to the hotel but please check with the hotel on 2/12 to ensure you get the IBM rate). I'm awaiting the meeting room charges from the hotel. For those who are staying at the Hyatt hotel, you may sign a form at the meetings to charge your room. For everyone else, you may write a check to the "Hyatt" at the meetings. I'll recruit a "collector" for each meeting. I confirmed we have the meeting room for the UPD discussion on the evening of Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy. Just ask for the meeting room for the Printer Working Group. For your information, I have appended the "ping" list after this note. Please notify me directly of any mistakes. Ok, back to my real job... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead MTE Software 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 ? Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Attendance by Date 3/2 3/3 3/4 3/5 3/6 16 17 25 23 13 From carterk at us.ibm.com Thu Feb 12 08:58:04 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> RESEND: PWG meeting in Austin on 3/2-6 Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> ---------------------- Forwarded by Keith Carter/Austin/IBM on 02-12-98 07:59 AM --------------------------- Keith Carter 02-11-98 04:24 PM To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet, pwg@pwg.org@internet, p1394@pwg.org@internet cc: From: Keith Carter/Austin/IBM @ IBMUS Subject: PWG meeting in Austin on 3/2-6 Print gurus, Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6. I've sent the information to the Hyatt hotel. You may start making your hotel reservations under "Printer Working Group" on Thursday, 2/12. The phone number for the Hyatt hotel is 512-477-1234. Reservations at the IBM rate of $101/night rate will be accepted through Tuesday, 2/17. If you make your reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't procrastinate. If you have already made your reservation, please contact the hotel on 2/12 and inform them you are with the "Printer Working Group" to get the IBM rate (several of you informed me that you already made your reservations so I forwarded this information to the hotel but please check with the hotel on 2/12 to ensure you get the IBM rate). I'm awaiting the meeting room charges from the hotel. For those who are staying at the Hyatt hotel, you may sign a form at the meetings to charge your room. For everyone else, you may write a check to the "Hyatt" at the meetings. I'll recruit a "collector" for each meeting. I confirmed we have the meeting room for the UPD discussion on the evening of Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy. Just ask for the meeting room for the Printer Working Group. For your information, I have appended the "ping" list after this note. Please notify me directly of any mistakes. Ok, back to my real job... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead MTE Software 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 ? Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Attendance by Date 3/2 3/3 3/4 3/5 3/6 16 17 25 23 13 From rbergma at dpc.com Thu Feb 12 10:52:35 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> PMP> I-D ACTION:draft-ietf-printmib-job-protomap-03.txt (fwd) Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1263157-3049-887298755=:123 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: ---------- Forwarded message ---------- Date: Thu, 12 Feb 1998 10:46:54 -0500 From: Internet-Drafts@ns.ietf.org To: IETF-Announce@ns.ietf.org Cc: pmp@pwg.org Subject: PMP> I-D ACTION:draft-ietf-printmib-job-protomap-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Title : Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB Author(s) : R. Bergman Filename : draft-ietf-printmib-job-protomap-03.txt Pages : 23 Date : 11-Feb-98 This Internet-Draft defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-protomap-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-printmib-job-protomap-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-protomap-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --1263157-3049-887298755=:123 Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="1263157-16427-887298755=:123" Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1263157-16427-887298755=:123 Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ds.internic.net" Content-ID: --1263157-16427-887298755=:123 Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-printmib-job-protomap-03.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --1263157-16427-887298755=:123-- --1263157-3049-887298755=:123-- From carterk at us.ibm.com Thu Feb 12 18:25:18 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> Hotel reservations for the Hyatt Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> Earlier today (Thursday, 2/12), the Hyatt hotel mistakenly told some people I was holding a block of rooms that I would reserve on everyone's behalf. This misunderstanding has been corrected. Everyone who was so informed, should make their own reservation with the hotel under "Printer Working Group" per our original plan. The hotel phone number is 512-477-1234. Also, please continue to send me pings on your attendance at the meetings so we have the most accurate headcount possible for the meetings. Thanks... Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From carterk at us.ibm.com Fri Feb 13 15:37:57 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: Hotel reservations for the Hyatt In-Reply-To: Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> Mabry wrote today (2/13): >Keith, > >How do you like your new job as travel agent? ;) > >Our travel dept tried to book me a room we have been told that the rate was "no >longer available", and mentioned something about all the rooms at that rate have >been "used up". This was tried yesterday. I just got off the phone myself, and >was told the same.... > >Any ideas what they are talking about? > >The rate I am being quoted is $165.00/night. Mabry, This job as travel agent is looking less appealing by the minute. I called the meeting coordinator at the Hyatt hotel who assured me they will fix this problem immediately. There are rooms available at the IBM rate. Please try again to make your reservation. Everyone, Anyone else who has encountered this problem, please try again to make your reservation. Sincerely, your travel agent, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From rbergma at dpc.com Mon Feb 16 11:12:10 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> IETF Printer Working Group: Request for IESG Consideration Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> The Printer MIB Working Group hereby requests IESG approval for publication of the following documents, as Informational RFCs. The working group has been developing the content of these documents for approximately 2 years and has reached a strong consensus for this set of specifications. The Job Monitoring MIB specification is requested to be published as an Informational as recommended by the Application Area Directors. This recommendation is based upon the use of the MIB to monitor a service node on the network rather than a network node proper. DOCUMENT: Job Monitoring MIB - V1 Status: Informational Technical Summary: This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. DOCUMENT: Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB Status: Informational Technical Summary: This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. ---------------------------------------------------------------------- Ron Bergman 805 578 4421 Dataproducts Corp. fax: 805 578 4005 1757 Tapo Canyon Road rbergma@dpc.com Simi Valley, California 93063-3394 ---------------------------------------------------------------------- From rbergma at dpc.com Tue Feb 17 20:31:39 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> Charter: Traps for use with the Job Monitoring MIB Message-ID: <3.0.1.32.19980210150619.0111ec90@garfield> Here is a draft charter to stimulate some discussion regarding Job MIB traps. This will be reviewed at the meeting in Austin, so get your comments in early. I am sending this to the PWG and JMP mail list in case this is of interest to somwone who is not on the JMP mail list. Anyone who desires to follow this subject in the future should join the JMP mail list. Job Monitoring MIB Traps ------------------------ Statement of Charter: This project shall develop an extension to the PWG Job Monitoring MIB that defines a set of SNMP traps related to monitoring of the status and progress of print jobs. Examples of some of the conditions that will be investigated for traps are: + Start of Job + End of Job + Job progress information (e.g. page counts) + Errors interrupting the Job + Job hold notification + Job release notification Traps were purposely not included in the current Job Monitoring MIB in an effort to limit the scope of the MIB development. In retrospect, this was an excellent decision since the Job Monitoring MIB proved to be a task more difficult than was initially imagined. With the Job Monitoring MIB development completed, is now an appropriate time to open this effort. It is also now evident that most implementations of a Job Monitoring MIB, either the PWG or Private version, have incorporated traps. It is the desire of the PWG to standardize the implementations of traps to provide for better interoperability of management applications and printers. Goals: One of the major obstacles expected in this project is the definition of a method for the registration of traps. There have been several registration methods recently proposed, most notably in the SNMP v3 documents. This project will examine all published methods and a unique method will be proposed only if an externally generated proposal is deficient. Methods relating to the generation and processing traps will also be included as discussion items. Specific goals in this area are dependent upon the results of the findings. Schedule: March meeting; - Establish Chairman, Editor, Secretary, etc. - Review charter and goals - Define trap types for consideration - Assignments for registration methods review - Scope effort relative to 'generation and processing traps' - Review and revise proposed schedule April meeting; - Finalize charter and goals - First cut at traps descriptions - Presentation of registration methods review - Text for 'generation and processing traps' May meeting; - Finalize traps descriptions - Select registration method(s) - Start registration method specification - Start draft of final document. July meeting; - Review registration method draft specification - Incorporate registration method in base document - First review of final document November meeting; - Final document ready to submit to the IESG Ron Bergman Dataproducts Corp. From imcdonal at eso.mc.xerox.com Tue Feb 17 23:00:12 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: PWG> Charter: Traps for use with the Job Monitoring MIB In-Reply-To: Charter: Traps for use with the Job Monitoring MIB> Message-ID: <9802180400.AA05069@snorkel.eso.mc.xerox.com> Hi Ron, Would you consider having a telecon during the upcoming PWG meeting in March, to widen the participation on the Job Mon MIB traps project discussion? All of the key people at Xerox who have participated in Xerox (private) specification of job monitoring traps and trap registration methods are unable to attend in March (I know - I've been checking with them). Thanks for pushing this IMPORTANT issue along. As the first PWG standard and NOT an IETF standard, I believe the PWG Job Mon MIB has a unique opportunity to address domain-specific traps sensibly and MUCH more quickly than could be done for an IETF 'standards track' document. To stimultate discussion, my two cents on trap registration 1) SNMPv3 carries way to much security baggage, to be a good trap registration method 2) There AREN'T any other IETF 'standards track' trap registration methods 3) A PWG standardized solution for the PWG Job Mon MIB could also EASILY be a PWG standardized solution for the IETF/PWG Printer MIB (different OID subtree) 4) A PWG standardized solution could EASILY be SNMP version independent (ie, SNMPv1, SNMPv1Secure[obsolete], SNMPv2Historic[RFC144x series], SNMPv2[RFC 190x series], and SNMPv3 [RFC227x series, last month]) Cheers, - Ira McDonald From rturner at sharplabs.com Wed Feb 18 04:25:41 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: PWG> Charter: Traps for use with the Job Monitoring MIB Message-ID: <9802180400.AA05069@snorkel.eso.mc.xerox.com> I'm assuming with the addition of traps for the job monitoring MIB, as well as the existing printer MIB traps (alerts), and our desire to include printer MIB alerts, as well as job notifications to IPP, we now have a completely redundant, overlapping solution set ;) ;) Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Tuesday, February 17, 1998 8:00 PM To: jmp@pwg.org; pwg@pwg.org; rbergma@dpc.com Subject: Re: PWG> Charter: Traps for use with the Job Monitoring MIB Hi Ron, Would you consider having a telecon during the upcoming PWG meeting in March, to widen the participation on the Job Mon MIB traps project discussion? All of the key people at Xerox who have participated in Xerox (private) specification of job monitoring traps and trap registration methods are unable to attend in March (I know - I've been checking with them). Thanks for pushing this IMPORTANT issue along. As the first PWG standard and NOT an IETF standard, I believe the PWG Job Mon MIB has a unique opportunity to address domain-specific traps sensibly and MUCH more quickly than could be done for an IETF 'standards track' document. To stimultate discussion, my two cents on trap registration 1) SNMPv3 carries way to much security baggage, to be a good trap registration method 2) There AREN'T any other IETF 'standards track' trap registration methods 3) A PWG standardized solution for the PWG Job Mon MIB could also EASILY be a PWG standardized solution for the IETF/PWG Printer MIB (different OID subtree) 4) A PWG standardized solution could EASILY be SNMP version independent (ie, SNMPv1, SNMPv1Secure[obsolete], SNMPv2Historic[RFC144x series], SNMPv2[RFC 190x series], and SNMPv3 [RFC227x series, last month]) Cheers, - Ira McDonald From carterk at us.ibm.com Fri Feb 20 09:24:55 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> IPP> UPD meeting Message-ID: <9802180400.AA05069@snorkel.eso.mc.xerox.com> >I have one of our printer driver guys that wants to come JUST for the >discussion on UPD. But I really need to able to tell him a firm agenda >for this meeting in Austin. Is there a final decision on when the UPD >meeting will be held? > >Thanx > >R. Ok, here's a stake in the lake. The UPD meeting will be 7:00PM-10:00PM CST on Tuesday, March 3. The meeting is in the Texas 5 meeting room. For directions to the room, look at the meeting board in the lobby or ask the hotel desk. I am recruiting a chair for the meeting who can then drive the agenda. I understand Paul Moore of Microsoft will discuss their Universal Print Driver at this meeting. Is there a UPD mailing list? Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From jds at underscore.com Fri Feb 20 09:52:16 1998 From: jds at underscore.com (Jeffrey D. Schnitzer) Date: Wed May 6 14:00:15 2009 Subject: JMP> UPD mailing list (was IPP> UPD meeting) Message-ID: <9802180400.AA05069@snorkel.eso.mc.xerox.com> Keith Carter asked: > > Is there a UPD mailing list? > The UPD mailing list is . To add yourself to the list, send mail to with the following as the body of the message: subscribe upd end The list has been in place since May'97, but there was little traffic on it. It's hypermail archive is at: http://www.pwg.org/hypermail/upd /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- From carterk at us.ibm.com Fri Feb 20 09:51:32 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> Meeting room information for PWG meeting in Austin on 3/2-6 Message-ID: <9802180400.AA05069@snorkel.eso.mc.xerox.com> Print gurus, The meeting room charge is $30 per person per day. When you check in at the Hyatt hotel, please inform the hotel person that you are with the "IBM Printer Working Group" and ask for the form to specify meeting room charges. Specify your total charges for the week (number of meeting days you will attend x $30) on the form, sign it, and return it to the hotel person. This charge will then be added to your hotel bill. For those who are not staying at the hotel, the chair of each PWG meeting will ask you to complete the form and return it to them with a check payable to the "Hyatt". There will be no charge for the UPD meeting on the evening of March 3 since we are using the same room as the 1394 working group. The meeting rooms by day are as follows: March 2-5 Texas 5 March 6 Foothills 1 Directions to these rooms should be on the meeting board in the lobby under "IBM Printer Working Group" or ask the hotel desk. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 From hastings at cp10.es.xerox.com Fri Feb 20 12:56:29 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> I've uploaded newest Ira McDonald's tools for producing IETF Message-ID: <3.0.1.32.19980220095629.010bf100@garfield> Ira has updated his tools, including fixing a bug, to: ftp://ftp.pwg.org/pub/pwg/tools/cscan.exe ftp://ftp.pwg.org/pub/pwg/tools/maxln.exe ftp://ftp.pwg.org/pub/pwg/tools/overx.exe ftp://ftp.pwg.org/pub/pwg/tools/strip.exe ftp://ftp.pwg.org/pub/pwg/tools/readme.txt These help in producing .txt files that follow IETF rules for ASCII files, with no special characters, and no lines longer than 72 characters. Here is the readme.txt file: Hi folks, Thursday (29 January 1998) The following files are in '/pub/pwg/tools/ (DOS executables): cscan.exe - Character Scan Utility maxln.exe - Maximum Line Length Scan Utility overx.exe - Overstrike Merge Utility strip.exe - Control Character Strip Utility Each of the programs has a -h option which explains the command line. Sometimes, MIBs produced with MS-WORD cannot be successfully stripped of headers and footers. The fix is to run my text utility 'overx', which folds line fragemnts from overstrike lines (fragments end in single carriage returns, without a following linefeed/newline) to combine them into a single canonical line - the 'generic text driver' with some or all versions of MS Word yields such overstrike lines when used with Tom's styles - I wrote 'overx' last year, to help Tom out - these latest Job Mon files caused me to find and fix a small bug in 'overx'. Ira McDonald, outside consultant to Xerox Corp. From bpenteco at boi.hp.com Fri Feb 27 18:30:42 1998 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:15 2009 Subject: JMP> Farewell after Austin Message-ID: <3.0.1.32.19980220095629.010bf100@garfield> I will be transferring to a new job within HP soon after the PWG meeting in Austin. My PWG responsibilities will be transferred to a number of people. I have enjoyed working with everyone in the group and I have learned a lot. Who knows, maybe our paths will cross in the future. See you in Austin, if you're there. Bob Pentecost HP From carterk at us.ibm.com Sat Feb 28 15:25:20 1998 From: carterk at us.ibm.com (Keith Carter) Date: Wed May 6 14:00:15 2009 Subject: JMP> PING list for PWG meetings Message-ID: <3.0.1.32.19980220095629.010bf100@garfield> Attached is the current ping list for the PWG meetings. I did not request pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is interested, please show up at the Texas 5 meeting room. Have a super day, Keith Carter Senior Software Engineer IBM Network Computing Software Division in Austin, Texas internet email: carterk@us.ibm.com Notes email: Keith Carter/Austin/IBM@IBMUS phone: 512-838-2155 tie-line: 678-2155 fax: 512-838-0169 PWG PING LIST AS OF 2/28/98 Name Company PWG Hyatt? Arrive Depart Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 Shivaun Albright HP 3/4-5 Y 3/3 3/5 Carlos Becerra HP 3/6 Y 3/5 3/6 Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 Brian Batchelder HP 3/2-3 Y 3/1 3/4 Alan Berkema HP 3/2-3 N - - - - Keith Carter IBM 3/4-5 N - - - - Roger deBry IBM 3/4-5 Y 3/3 3/5 Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 Lee Farrell Canon 3/2-6 Y 3/1 3/6 Richard Hart Digital 3/4-6 Y 3/3 3/6 Tom Hastings XEROX 3/4-6 Y 3/3 3/6 Marvin Heffler IBM 3/4-5 N - - - - Bob Herriot SUN 3/4-5 Y 3/3 3/6 Osamu Hirata Canon 3/2-3 Y 3/1 3/4 Stephen Holmstead HP 3/2-3 Y 3/1 3/3 Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 Takashi Isoda Canon 3/2-3 Y 3/1 3/5 Scott Isaacson Novell 3/4-5 Y 3/3 3/5 David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 Greg LeClair EPSON 3/2-4 Y 3/1 3/4 Harry Lewis IBM 3/4-6 Y 3/3 3/6 Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 Jay Martin Underscore 3/4-5 Y 3/3 3/6 Peter Michalek Shinesoft 3/4-5 N - - - - Paul Moore Microsoft 3/4 Y 3/3 3/4 Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 Bob Pentecost HP 3/4-6 Y 3/3 3/6 Yuji Sasaki - - - - 3/2-5 N - - - - Kris Schoff HP 3/4-5 ? ? ? Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 Greg Shue HP 3/2-3 Y 3/1 3/3 Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 Jim Walker DAZEL 3/4-6 N - - - - Don Wright Lexmark 3/2-6 Y 3/1 3/6 Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 Peter Zehler XEROX 3/4-5 Y 3/3 3/6 PWG Meeting Confirmed Attendance by Date P1394 P1394 IPP IPP JMP/FIN 3/2 3/3 3/4 3/5 3/6 20 21 32 29 14 Additional people who might attend. I do not know which meetings they will attend. Mike Fenelon Microsoft ? ? ? ? ? Shockey JRL Systems ? N - - - - From mark at mtesoft.com Sat Feb 28 17:28:39 1998 From: mark at mtesoft.com (Mark T. Edmead) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: PWG> PING list for PWG meetings Message-ID: <3.0.1.32.19980220095629.010bf100@garfield> Keith: Unfortunately, due to my being sick with the flu, I will have to cancel my trip to Austin... --Mark **************************************************************** Mark T. Edmead MTE Software, Inc. Microsoft Windows Systems Design and Engineering Consultants Microsoft Certified Solution Providers 3645 Ruffin Road, Suite 350 San Diego, CA 92123 (619) 292-2050 (619) 292-5977 FAX http://www.mtesoft.com e-mail: mark@mtesoft.com ********************************************************* _\^|^/_ (o o) --o0O0----(_)----0O0o-- On Saturday, February 28, 1998 12:25 PM, Keith Carter [SMTP:carterk@us.ibm.com] wrote: > Attached is the current ping list for the PWG meetings. I did not request > pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is > interested, please show up at the Texas 5 meeting room. > > Have a super day, > > Keith Carter > Senior Software Engineer > IBM Network Computing Software Division in Austin, Texas > internet email: carterk@us.ibm.com > Notes email: Keith Carter/Austin/IBM@IBMUS > phone: 512-838-2155 > tie-line: 678-2155 > fax: 512-838-0169 > > PWG PING LIST AS OF 2/28/98 > > Name Company PWG Hyatt? Arrive Depart > > Chuck Adams Tektronix 3/4-6 Y 3/3 3/6 > Shivaun Albright HP 3/4-5 Y 3/3 3/5 > Carlos Becerra HP 3/6 Y 3/5 3/6 > Ron Bergman Dataproducts 3/4-6 Y 3/3 3/6 > Brian Batchelder HP 3/2-3 Y 3/1 3/4 > Alan Berkema HP 3/2-3 N - - - - > Keith Carter IBM 3/4-5 N - - - - > Roger deBry IBM 3/4-5 Y 3/3 3/5 > Mabry Dozier QMS Inc. 3/4-6 Y 3/3 3/6 > Mark Edmead Warp Nine 3/2-3 Y 3/1 3/4 > Lee Farrell Canon 3/2-6 Y 3/1 3/6 > Richard Hart Digital 3/4-6 Y 3/3 3/6 > Tom Hastings XEROX 3/4-6 Y 3/3 3/6 > Marvin Heffler IBM 3/4-5 N - - - - > Bob Herriot SUN 3/4-5 Y 3/3 3/6 > Osamu Hirata Canon 3/2-3 Y 3/1 3/4 > Stephen Holmstead HP 3/2-3 Y 3/1 3/3 > Henrik Holst i-data Int'l 3/2-5 Y 3/1 3/6 > Takashi Isoda Canon 3/2-3 Y 3/1 3/5 > Scott Isaacson Novell 3/4-5 Y 3/3 3/5 > David Kellerman Northlake SW 3/4-6 Y 3/3 3/6 > Greg LeClair EPSON 3/2-4 Y 3/1 3/4 > Harry Lewis IBM 3/4-6 Y 3/3 3/6 > Carl-Uno Manros XEROX 3/4-5 Y 3/3 3/5 > Jay Martin Underscore 3/4-5 Y 3/3 3/6 > Peter Michalek Shinesoft 3/4-5 N - - - - > Paul Moore Microsoft 3/4 Y 3/3 3/4 > Yoshinori Murakami EPSON 3/2-3 Y 3/1 3/4 > Fumio Nagasaka EPSON 3/2-4 Y 3/1 3/5 > Bob Pentecost HP 3/4-6 Y 3/3 3/6 > Yuji Sasaki - - - - 3/2-5 N - - - - > Kris Schoff HP 3/4-5 ? ? ? > Hitoshi Sekine Microsoft 3/2-3 Y 3/1 3/4 > Akihiro Shimura Canon 3/2-3 Y 3/1 3/5 > Greg Shue HP 3/2-3 Y 3/1 3/3 > Larry Stein Warp Nine 3/2-3 Y 3/1 3/4 > Philip Thambidurai Okidata 3/3-5 Y 3/2 3/6 > Jerry Thrasher Lexmark 3/2-3 Y 3/1 3/4 > Randy Turner Sharp Labs 3/2-5 Y 3/1 3/6 > Bill Wagner OSICOM/DPI 3/2-6 Y 3/2 3/6 > Jim Walker DAZEL 3/4-6 N - - - - > Don Wright Lexmark 3/2-6 Y 3/1 3/6 > Lloyd Young Lexmark 3/4-6 Y 3/3 3/6 > Peter Zehler XEROX 3/4-5 Y 3/3 3/6 > > > PWG Meeting Confirmed Attendance by Date > > P1394 P1394 IPP IPP JMP/FIN > 3/2 3/3 3/4 3/5 3/6 > 20 21 32 29 14 > > Additional people who might attend. I do not know which meetings they will > attend. > > Mike Fenelon Microsoft ? ? ? ? > ? Shockey JRL Systems ? N - - - - From imcdonal at eso.mc.xerox.com Wed Mar 4 22:34:47 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> JAM MIB - trap registration idea Message-ID: <9803050334.AA08589@snorkel.eso.mc.xerox.com> Copies To: jmp@pwg.org hastings@cp10.es.xerox.com Hi folks, Wednesday (4 March 1998) In response to Ron Bergman's recent request that people post concrete ideas about SNMP trap registration mechanisms, I just posted the text of a work-in-progress MIB written by Joe Filion (Xerox) and Ira McDonald (High North) to the PWG FTP server in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ SYNOPSIS ------------------------------------------------------------------------ This document specifies the Job Async Monitoring (JAM) MIB, an individual contribution to the Job Monitoring Project (JMP) of the Printer Working Group (PWG), a work-in-progress MIB module for the entire printer industry, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The JAM MIB specifies a lightweight SNMP trap registration mechanism for end-user clients, management stations, and management proxies. This SNMP trap registration mechanism is SNMP protocol version independent. This SNMP trap registration mechanism is security scheme independent. The JAM MIB is a companion to the PWG Job Monitoring MIB and the IETF/PWG Printer MIB (published separately). The JAM MIB is UNENCUMBERED by any patents pending or granted or other intellectual property considerations. ------------------------------------------------------------------------ FILES ------------------------------------------------------------------------ These files are in 'ftp://ftp.pwg.org/pub/pwg/jmp/contributions': rel_0304.txt - this release note jam_v010.txt - Job Async Monitoring MIB v0.10 - text w/ formfeeds jam_v010.mib - Job Async Monitoring MIB v0.10 - ASN.1 source From harryl at us.ibm.com Tue Mar 10 11:23:56 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:15 2009 Subject: JMP> Austin JMP (trap) minutes Message-ID: <9803050334.AA08589@snorkel.eso.mc.xerox.com> I have uploaded the meeting minutes for the March meeting in Austin. ftp://ftp.pwg.org/pub/pwg/jmp/minutes/jmp-0398.pdf The file is also available in HTML. IPP Notification folks may want to review item (3) under the "Job MIB t= rap topics" section. Here you will find a list of Notification Types (calle= d trap types for JMP) and a table of Notification content, per type. This shou= ld be useful for IPP notification, as well. Harry Lewis - IBM Printing Systems = From imcdonal at eso.mc.xerox.com Sun Mar 15 19:35:07 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> SNMPv3 unsuited for IPP/JMP Notifications Message-ID: <9803160035.AA12733@snorkel.eso.mc.xerox.com> Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From jkm at underscore.com Mon Mar 16 16:46:33 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: IPP> SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <9803160035.AA12733@snorkel.eso.mc.xerox.com> Ira, Thanks so much for your review and comments regarding the applicability (or not) of the new SNMPv3 async notification facilities. I particularly liked your summary paragraph: > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. This comes as no surprise to those of us developing SENSE over the last two years or so. SNMP was primarily designed for management network elements, and has never demonstrated the power required in larger, non-management applications, such as generic client-side features of network printing. That is precisely why we went off and did SENSE, to create a more scalable, more generic system for async notifications. Simply hacking onto existing (or future) SNMP facilities never seemed to make the grade. And now your analysis seems to verify that original assumption. Perhaps someday the PWG will come to understand the need for SENSE...or something just like it, anyway. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- Ira Mcdonald x10962 wrote: > > Copies To: ipp@pwg.org > jmp_pwg.org > > Hi folks, Sunday (15 March 1998) > > Extracted below (with line numbers) is summary information from the five > SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). > > As Randy Turner has argued, it IS possible to use a small subset (Target > and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are > a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) > SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' > declaration at line 2773 of RFC 2273). > > But, the functionality provided is INFERIOR in important ways to that > provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted > on Wednesday (4 March 1998) or to my informal understanding of the IBM > method presented by Harry Lewis during last week's PWG monthly meeting > in Austin, TX. > > 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope > (traps of 'interest') specified as object identifier subtrees. > The SNMPv3 Target/Notification MIBs support scope only by short (32 > character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due > to their length) are NOT amenable to standardization. > > 2) The JAM MIB supports automatic trap deregistration specified as > 'DateAndTime'. > The SNMPv3 Target/Notification MIBs do NOT support automatic trap > deregistration at all! > > 3) The JAM MIB supports simple integer indices for all 'read-create' > object groups (written by a remote client). > The SNMPv3 Target/Notification MIBs support indices ONLY as (32 > character) UTF-8 'SnmpAdminString' values, seriously restricting the > number of SNMP objects which can be transferred in a single packet. > Since SNMP runs over UDP (in the Internet suite) and there is no > 'chunking' for SNMP requests, this limitation is significant! > > 4) The JAM MIB supports a 'read-only' lookup table (maintained by the > SNMP agent on the device) which provides direct lookup from SNMP > transport domain and transport address to a client (target) trap > registration entry (to avoid duplicate registrations). > But, the SNMPv3 Target/Notification MIBs support only brute force > (ie, read the entire Target table) for this important functionality! > > 5) The JAM MIB scales well to a very large number of (end-user) trap > client (target) registrations. > But, the SNMPv3 Target/Notification MIBs do not scale well. They > are intended ONLY for use by network management stations! > > 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses > could be used for (questionably) 'reliable' event notification. > But, 'Inform' is intended by the SNMPv3 developers to be used ONLY > for reporting up a hierarchy of network management stations! > Also, 'Inform' is not defined in SNMPv1, so the huge installed base > of SNMP agents which (almost exclusively) speak SNMPv1 cannot use > 'Inform'. > > 7) Lastly, as SNMP agent toolkits become available from software tool > vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the > printer industry vendors will inevitably conflict with the very > different intent of the SNMPv3 developers. Recall why the Job Mon > MIB is a PWG standard and NOT an IETF standard! > > As I hope most of you know, I'm dedicated to the use of standards where > available and applicable. But the SNMPv3 MIBs were never intended to be > used by many clients. They simply aren't appropriate to the problem of > trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. > > Cheers, > - Ira McDonald (High North, outside consultant at Xerox) > > ------------------------------------------------------------------------ > **** SNMPv3 Documents **** > > rfc2271.txt: Architecture for Describing SNMP Management Frameworks > - 38-44: > This document describes an architecture for describing SNMP > Management Frameworks. The architecture is designed to be modular to > allow the evolution of the SNMP protocol standards over time. The > major portions of the architecture are an SNMP engine containing a > Message Processing Subsystem, a Security Subsystem and an Access > Control Subsystem, and possibly multiple SNMP applications which > provide specific functional processing of management data. > - 1913: > SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN > - 2420: > snmpFrameworkMIBCompliance MODULE-COMPLIANCE > > rfc2272.txt: Message Processing and Dispatching for SNMP > - 41-46: > This document describes the Message Processing and Dispatching for > SNMP messages within the SNMP architecture [RFC2271]. It defines the > procedures for dispatching potentially multiple versions of SNMP > messages to the proper SNMP Message Processing Models, and for > dispatching PDUs to SNMP applications. This document also describes > one Message Processing Model - the SNMPv3 Message Processing Model. > - 810: > SNMP-MPD-MIB DEFINITIONS ::= BEGIN > - 936: > snmpMPDCompliance MODULE-COMPLIANCE > - 976: > SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > > rfc2273.txt: SNMPv3 Applications > - 37-44: > This memo describes five types of SNMP applications which make use of > an SNMP engine as described in [RFC2271]. The types of application > described are Command Generators, Command Responders, Notification > Originators, Notification Receivers, and Proxy Forwarders. > > This memo also defines MIB modules for specifying targets of > management operations, for notification filtering, and for proxy > forwarding. > - 1561: > SNMP-TARGET-MIB DEFINITIONS ::= BEGIN > - 2209: > snmpTargetCommandResponderCompliance MODULE-COMPLIANCE > - 2305: > SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN > - 2773: > snmpNotifyBasicCompliance MODULE-COMPLIANCE > - 2881: > snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE > - 2894: > snmpNotifyFullCompliance MODULE-COMPLIANCE > - 2960: > SNMP-PROXY-MIB DEFINITIONS ::= BEGIN > - 3242: > snmpProxyCompliance MODULE-COMPLIANCE > > rfc2274.txt: User-based Security Model (USM) for SNMPv3 > - 37-41: > This document describes the User-based Security Model (USM) for SNMP > version 3 for use in the SNMP architecture [RFC2271]. It defines the > Elements of Procedure for providing SNMP message level security. > This document also includes a MIB for remotely monitoring/managing > the configuration parameters for this Security Model. > - 861: > USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN > - 1701: > SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN > - 2439: > usmMIBCompliance MODULE-COMPLIANCE > > rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 > - 38-42: > This document describes the View-based Access Control Model for use > in the SNMP architecture [RFC2271]. It defines the Elements of > Procedure for controlling access to management information. This > document also includes a MIB for remotely managing the configuration > parameters for the View-based Access Control Model. > - 541: > SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN > - 1356: > vacmMIBCompliance MODULE-COMPLIANCE > ------------------------------------------------------------------------ From rturner at sharplabs.com Tue Mar 17 13:23:01 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications Message-ID: <9803160035.AA12733@snorkel.eso.mc.xerox.com> I am not sure what the dissenting opinion is, whether SNMPv3 is not the correct solution? Or, is the proposed notification MIB not the right solution? If SNMP is the wrong solution, then any SNMP-accessed MIB would be the wrong solution, including the JAM MIB. I will try and address the concerns outlined below, with matching numbers. 1) Scopes of interest are still supported by OID subtree specifications; it's the intended notification recipients that are identified and matched by the UTF-8 tag. 2) Registration lifetimes would be a good idea. It's quite possible for an IPP MIB to augment the notification table with objects that represent registration lifetimes. No need to throw the baby out with the bath water on this one. Since it is an explicit augmentation, the indices would be the same. 3) Indices that appear as SnmpAdminString types are labeled as NOT-ACCESSIBLE, so they should not appear in the response packet of a GET, or GET-BULK. 4) I'm not sure if a brute force search would be required or not (yet). It appears from reading the RFC that this might be the case and I understand how this conclusion could be made. However, I'm not sure that duplicate registrations could be identified solely on the basis of "transport" and "transport-address" matching. This particular scenario would require more study. 5) This rationale does not exist for SNMPv3. This held true only for V2 (and derivatives). All the text about "dual-role entities" from V2 has been removed from the V3 doc set. The V3 specs now generically identify "notification senders" and "notification recipients". The idea of specific functionality being reserved for a "mid-level" manager entity no longer exists. Implementors are free to instrument whatever feature they need, depending upon the type of management (or managed) entity is being constructed. 6) Again, this idea is a V2 idea, the restrictions on "how" a feature is used has been removed from the V3 specifications. See #5 above. Also, I have it on good authority from Jeff Case at SNMP Research, that the effort required to take the V1 trap code base and move it to V3 trap/inform is no great task. A lot of code reuse is possible. Also, V3 informs are as reliable as any other notification mechanism. 7) Again, I have it on first hand communication from Bob Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their "intent" was never to disallow the type of functionality I have proposed. Rather, it seems like a prudent reuse of all vendors' existing agent code base. This reuse of technology (both in design and existing code) is what I am trying to take advantage of. Given the speed at which SNMPv3 is being adopted, I feel like a lot of vendors are going to want to implement V3 agents anyway. Also, after looking at Ira's proposal for the JAM MIB, there are some ideas present in the JAM MIB that were not included in the standard notification/target MIBs specified in RFC 2273. I think we should include these ideas in whatever we come up with. I don't think we should completely reinvent the wheel here, rather, I think we should come up with a suitable set of additional (non-overlapping) notification features and AUGMENT the standard set. This is because, for a lot of reasons, I think vendors will eventually have to support them anyway to be "V3 compliant" at some point in the future. By the way, I have no SNMP religious affiliation, just a desire to reuse technology. If we find out that our requirements exceed the boundaries of what SNMPv3 and related technology can deliver, then I would be just as happy to pursue another path. But I think we need to study this stuff a little more before taking any radical direction change. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 15, 1998 4:35 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org jmp_pwg.org Hi folks, Sunday (15 March 1998) Extracted below (with line numbers) is summary information from the five SNMPv3 documents (RFC 2271 to RFC 2275, January 1998). As Randy Turner has argued, it IS possible to use a small subset (Target and Notification MIBs in RFC 2273) of the SNMPv3 MIB modules (there are a total of 7 SNMPv3 MIB modules) to achieve a simple (security-free) SNMP trap registration mechanism (see the 'snmpNotifyBasicCompliance' declaration at line 2773 of RFC 2273). But, the functionality provided is INFERIOR in important ways to that provided by the JAM (Job Async Monitor) MIB that Joe Filion and I posted on Wednesday (4 March 1998) or to my informal understanding of the IBM method presented by Harry Lewis during last week's PWG monthly meeting in Austin, TX. 1) The JAM MIB and Historic SNMP Party MIB (RFC 1447) support scope (traps of 'interest') specified as object identifier subtrees. The SNMPv3 Target/Notification MIBs support scope only by short (32 character) UTF-8 tags, which are NOT standardized by SNMPv3 and (due to their length) are NOT amenable to standardization. 2) The JAM MIB supports automatic trap deregistration specified as 'DateAndTime'. The SNMPv3 Target/Notification MIBs do NOT support automatic trap deregistration at all! 3) The JAM MIB supports simple integer indices for all 'read-create' object groups (written by a remote client). The SNMPv3 Target/Notification MIBs support indices ONLY as (32 character) UTF-8 'SnmpAdminString' values, seriously restricting the number of SNMP objects which can be transferred in a single packet. Since SNMP runs over UDP (in the Internet suite) and there is no 'chunking' for SNMP requests, this limitation is significant! 4) The JAM MIB supports a 'read-only' lookup table (maintained by the SNMP agent on the device) which provides direct lookup from SNMP transport domain and transport address to a client (target) trap registration entry (to avoid duplicate registrations). But, the SNMPv3 Target/Notification MIBs support only brute force (ie, read the entire Target table) for this important functionality! 5) The JAM MIB scales well to a very large number of (end-user) trap client (target) registrations. But, the SNMPv3 Target/Notification MIBs do not scale well. They are intended ONLY for use by network management stations! 6) Randy has suggested that SNMPv2/SNMPv3 'Inform' requests/responses could be used for (questionably) 'reliable' event notification. But, 'Inform' is intended by the SNMPv3 developers to be used ONLY for reporting up a hierarchy of network management stations! Also, 'Inform' is not defined in SNMPv1, so the huge installed base of SNMP agents which (almost exclusively) speak SNMPv1 cannot use 'Inform'. 7) Lastly, as SNMP agent toolkits become available from software tool vendors, any 'local' use of SNMPv3 Target/Notification MIBs by the printer industry vendors will inevitably conflict with the very different intent of the SNMPv3 developers. Recall why the Job Mon MIB is a PWG standard and NOT an IETF standard! As I hope most of you know, I'm dedicated to the use of standards where available and applicable. But the SNMPv3 MIBs were never intended to be used by many clients. They simply aren't appropriate to the problem of trap registration for PWG Job Mon MIB and IETF/PWG Printer MIB traps. Cheers, - Ira McDonald (High North, outside consultant at Xerox) ------------------------------------------------------------------------ **** SNMPv3 Documents **** rfc2271.txt: Architecture for Describing SNMP Management Frameworks - 38-44: This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. - 1913: SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN - 2420: snmpFrameworkMIBCompliance MODULE-COMPLIANCE rfc2272.txt: Message Processing and Dispatching for SNMP - 41-46: This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. - 810: SNMP-MPD-MIB DEFINITIONS ::= BEGIN - 936: snmpMPDCompliance MODULE-COMPLIANCE - 976: SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN rfc2273.txt: SNMPv3 Applications - 37-44: This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. - 1561: SNMP-TARGET-MIB DEFINITIONS ::= BEGIN - 2209: snmpTargetCommandResponderCompliance MODULE-COMPLIANCE - 2305: SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN - 2773: snmpNotifyBasicCompliance MODULE-COMPLIANCE - 2881: snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE - 2894: snmpNotifyFullCompliance MODULE-COMPLIANCE - 2960: SNMP-PROXY-MIB DEFINITIONS ::= BEGIN - 3242: snmpProxyCompliance MODULE-COMPLIANCE rfc2274.txt: User-based Security Model (USM) for SNMPv3 - 37-41: This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. - 861: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN - 1701: SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN - 2439: usmMIBCompliance MODULE-COMPLIANCE rfc2275.txt: View-based Access Control Model (VACM) for SNMPv3 - 38-42: This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. - 541: SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN - 1356: vacmMIBCompliance MODULE-COMPLIANCE ------------------------------------------------------------------------ From imcdonal at eso.mc.xerox.com Fri Mar 20 20:13:56 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Last Call on Printer MIB v2 Message-ID: <9803210113.AA15517@snorkel.eso.mc.xerox.com> Hi folks, Friday (20 March 1998) Note that Lloyd Young (co-chair of Printer MIB Working Group) started a working group 'last call' on the latest Printer MIB v2 draft yesterday (see his note below, with URLs). As a courtesy to the working group members I'm forwarding his note with an obvious subject line. Although Lloyd didn't state a time period for the 'last call', a two-week period is customary in IETF chartered working groups (and the IPP and JMP teams have recently used two-week working group 'last calls'), so I suggest that this Printer MIB 'last call' should close on Thursday (2 April). As Lloyd notes below, the updated Host Resources MIB in SMIv2 was posted last week (thanks to Jay Martin for bringing this to our attention): ftp://ds.internic.net/internet-drafts/draft-krupczak-hostmibv2-00.txt This MIB is an straight rewrite of the original Host Resources MIB (RFC 1514) in SMIv2, except that the 'hrPrinterDetectedErrorState' bits were added (as requested by the PWG). I sent some comments and questions to Bobby Krupczak (editor) and learned that Bobby has done this work as an individual contribution, with the approval of Harald Alvestrand, but the HR MIB Working Group has NOT been reconvened. Bobby said, in a note to me, that the idea is to move the HR MIB along the Internet 'standards track' quickly, "sufficient independent implemementation experience exists (that is, there are several independent implementations) and we wanted to push it forward without major changes." Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: lpyoung@lexmark.com >To: pmp@pwg.org >Date: Thu, 19 Mar 1998 11:33:17 PST >Subject: PMP> Latest Printer MIB draft > >I have made the NMSReset change to the Printer MIB that was >discussed in Austin. The latest revisions are: > >ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_0311698.txt >ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_0311698.pdf >ftp://ftp.pwg.org/pub/pwg/pmp/drafts/pmib_0311698_changes.pdf > >The TXT file is for those who cannot read PDF files. The >CHANGES.PDF file has revision marks by the changes that I made. > >I am not sure that I have ever done a formal two week last call >for changes to the Printer MIB document. Let this e-mail serve >as the last call. The Host Resources MIB has been published as >an Internet Draft and I want to be ready at a moments notice >to start pushing the Printer MIB forward as soon as something >happens to the HR MIB. > >Regards, >Lloyd > >------------------------------------------------------------ >Lloyd Young Lexmark International, Inc. >Senior Program Manager Dept. C14L/Bldg. 035-3 >Strategic Alliances 740 New Circle Road NW >internet: lpyoung@lexmark.com Lexington, KY 40550 >Phone: (606) 232-5150 Fax: (606) 232-6740 >----------------------------------------------------------------------< From imcdonal at eso.mc.xerox.com Sun Mar 22 12:36:47 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: SNMPv3 unsuited for IPP/JMP Notificiations In-Reply-To: Message-ID: <9803221736.AA15842@snorkel.eso.mc.xerox.com> Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From rturner at sharplabs.com Sun Mar 22 17:56:06 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notificiations> Message-ID: <9803221736.AA15842@snorkel.eso.mc.xerox.com> There two questions that have yet to be answered. You've repeatedly stated that SNMPv3 is not intended for "very many notification clients". I would like to hear a technical analysis of why you think this is the case. Also, I think its VERY unrealistic that an embedded device will have to manage "several hundred" client notification requests. If every client can specify a totally different object set to be sent along with each notification, then I don't think this is realistic for embedded devices. If you have a defined trap/notification, with a specific list of objects that are returned, then a notification originator only has to keep track of transport domains and addresses, not every combination of object sets that "possibly hundreds of notification clients" might want to know about. I don't think SNMPv3 is heavyweight. It's designed be implemented in everything from $300 managed 100Mbit hubs, all the way to enterprise ATM switches. And I think whatever solution we come up with will have to have the capability to support a distributed event notification system, similar to the way SENSE and other distributed notification mechanisms remove the burden from individual embedded printers from having to keep up with the entire world of notifications. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 9:37 AM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) I think you misunderstood several of my comments. My replies are in your note below, preceded by 'IEM>'. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'imcdonal@eso.mc.xerox.com'" , > Joe_Filion@mc.xerox.com, ipp@pwg.org, jmp@pwg.org >Subject: RE: IPP> SNMPv3 unsuited for IPP/JMP Notifications >Date: Tue, 17 Mar 1998 10:23:01 PST > >I am not sure what the dissenting opinion is, whether SNMPv3 is not the >correct solution? Or, is the proposed notification MIB not the right >solution? > >If SNMP is the wrong solution, then any SNMP-accessed MIB would be the >wrong solution, including the JAM MIB. IEM> The entire SNMPv3 MIB suite is unsuited to supporting very many end-user clients registered for notifications. But, the SNMPv1 suite is QUITE appropriate (and ubiquitously deployed) for basic monitoring (and sometimes active management) of networked systems and devices. >I will try and address the concerns outlined below, with matching >numbers. > >1) Scopes of interest are still supported by OID subtree >specifications; it's the intended notification recipients that are >identified and matched by the UTF-8 tag. IEM> No, OID subtrees are NOT in the SNMPv3 Notification or Target MIBs. Only local-scope tags (non-standardized names for groups of attributes) are specified in the Notification MIB. OID subtrees are in the SNMPv3 View-based Access Control Model MIB (RFC 2275), but ONLY with additional support of the user ('principal') security identifications accomplished via the User-based Security Model MIB (RFC 2274). That is, it takes the whole ball-of-wax of SNMPv3 MIBs to get to OID subtree views and they STILL aren't designed for fine-grained control (like individual traps, which are ONLY intended to be controlled via the Notification MIB). >2) Registration lifetimes would be a good idea. It's quite possible >for an IPP MIB to augment the notification table with objects that >represent registration lifetimes. No need to throw the baby out with the >bath water on this one. Since it is an explicit augmentation, the >indices would be the same. IEM> Augmenting an inappropriate scheme (SNMPv3) won't help. >3) Indices that appear as SnmpAdminString types are labeled as >NOT-ACCESSIBLE, so they should not appear in the response packet of a >GET, or GET-BULK. IEM> There is much confusion about 'not-accessible' indices. In ALL versions of SNMP (and OSI CMIP), the so-called 'variable bindings' are lists of full MIB object OIDs with SUFFIXED 'instance qualifiers', which are the VALUES of all the indices (so non-integer indices greatly reduce the efficiency of SNMP protocol exchanges). >4) I'm not sure if a brute force search would be required or not >(yet). It appears from reading the RFC that this might be the case and I >understand how this conclusion could be made. However, I'm not sure that >duplicate registrations could be identified solely on the basis of >"transport" and "transport-address" matching. This particular scenario >would require more study. IEM> In ALL versions of SNMP trap registration, duplicate registrations are determined solely on the basis of 'transport domain' and 'transport address' matching (all the way back to the Historic SNMPv1 Party MIB, RFC 1353). Because SNMPv3 is too heavyweight for a given low-level device to have many registered 'notification targets', the brute force search doesn't matter much, but for the printer industry scenarios of (potentially) hundreds of registered trap clients, the results would be catastrophic. >5) This rationale does not exist for SNMPv3. This held true only >for V2 (and derivatives). All the text about "dual-role entities" from >V2 has been removed from the V3 doc set. The V3 specs now generically >identify "notification senders" and "notification recipients". The idea >of specific functionality being reserved for a "mid-level" manager >entity no longer exists. Implementors are free to instrument whatever >feature they need, depending upon the type of management (or managed) >entity is being constructed. IEM> The SNMPv3 specs do NOT clarify appropriate use of 'Inform', as David Perkins has repeatedly criticized. The use of 'Inform' PDUs for directly acknowledgemed notifications to/from a EACH printer device to (potentially) hundreds of registered clients would fail utterly to scale in an enterprise network environment. >6) Again, this idea is a V2 idea, the restrictions on "how" a >feature is used has been removed from the V3 specifications. See #5 >above. Also, I have it on good authority from Jeff Case at SNMP >Research, that the effort required to take the V1 trap code base and >move it to V3 trap/inform is no great task. A lot of code reuse is >possible. Also, V3 informs are as reliable as any other notification >mechanism. IEM> See my comment below. >7) Again, I have it on first hand communication from Bob >Stewart(Cisco), Jeff Case and David Levi(SNMP Research) that their >"intent" was never to disallow the type of functionality I have >proposed. Rather, it seems like a prudent reuse of all vendors' existing >agent code base. IEM> The new PDUs for SNMPv2 were first published five years ago (1993). Nonetheless, almost ALL installed products speak SNMPv1 ONLY. A small minority support SNMPv1/SNMPv2 'hybrid agents'. Many of those became obsolete when the original SNMPv2 specifications (RFC 144x series) were abandoned and replaced with the (incompatible) current SNMPv2 specs (RFC 190x series) in January 1996. Many of the 'big names' in open management stations STILL only support SNMPv1 protocol. Quite a few STILL won't compile an SMIv2 dialect MIB (remember the SMI dialect is INDEPENDENT of the version of 'over-the-wire' SNMP protocol). It is inconceivable that customers will upgrade their open management control centers just to get at (newly incompatible) SNMPv3-based printers! >This reuse of technology (both in design and existing code) is what I am >trying to take advantage of. Given the speed at which SNMPv3 is being >adopted, I feel like a lot of vendors are going to want to implement V3 >agents anyway. Also, after looking at Ira's proposal for the JAM MIB, >there are some ideas present in the JAM MIB that were not included in >the standard notification/target MIBs specified in RFC 2273. I think we >should include these ideas in whatever we come up with. I don't think we >should completely reinvent the wheel here, rather, I think we should >come up with a suitable set of additional (non-overlapping) notification >features and AUGMENT the standard set. This is because, for a lot of >reasons, I think vendors will eventually have to support them anyway to >be "V3 compliant" at some point in the future. > >By the way, I have no SNMP religious affiliation, just a desire to reuse >technology. If we find out that our requirements exceed the boundaries >of what SNMPv3 and related technology can deliver, then I would be just >as happy to pursue another path. But I think we need to study this stuff >a little more before taking any radical direction change. > >Randy >----------------------------------------------------------------------< From imcdonal at eso.mc.xerox.com Sun Mar 22 19:37:08 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Message-ID: <9803230037.AA15969@snorkel.eso.mc.xerox.com> Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From rturner at sharplabs.com Sun Mar 22 20:04:26 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <9803230037.AA15969@snorkel.eso.mc.xerox.com> Your scalability rationale essentially boils down to string indices, since not all SNMPv3 implementations have to implement security via shared secrets. I don't think this single rationale is enough to dismiss on a scalability question. All along we've been talking about how to scale things down enough to make things "simple, lightweight", including talk about a much lighter weight protocol for host-to-device communication, where a notification protocol might be used. For you to bring up the fact that Xerox and other vendors have up to 1 million dollar printers is an argument for many notifications, but doesn't make much sense in the context of our heretofore previous discussions. You even talk about "1 million dollar printers" and "VERY lightweight" in the same paragraph ;) ;) I will reiterate my belief that I don't think its realistic for a simple embedded device to maintain notification info for hundreds of clients. I don't think its in the notification requirements document...maybe we should talk about the number of notifications that an embedded device should minimally support? And include the outcome of that discussion in the requirements doc. Also, I used my managed device examples (small hub to enterprise switch) to illustrate low-cost to high-cost devices with very wide variances in burden cost for manufacturing (memory, power, cpu, etc.). Maybe what we are actually debating is semantics in how we define "lightweight" and "heavyweight" Does lightweight mean simple to build (overall)? Simple to code? Lightweight in terms of CPU cycles? Other? It sometimes sounds like we are defining terms differently. Randy -----Original Message----- From: imcdonal@eso.mc.xerox.com [SMTP:imcdonal@eso.mc.xerox.com] Sent: Sunday, March 22, 1998 4:37 PM To: Joe_Filion@mc.xerox.com; ipp@pwg.org; jmp@pwg.org Subject: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications Copies To: ipp@pwg.org, jmp@pwg.org, Joe_Filion@mc.xerox.com Hi Randy, Sunday (22 March 1998) My replies are imbedded in your note below, preceded by 'IEM>'. I tried to answer each of your questions. Cheers, - Ira McDonald (High North) >----------------------------------------------------------------------< >From: "Turner, Randy" >To: "'ipp@pwg.org'" , "'jmp@pwg.org'" >Subject: RE: IPP> Re: SNMPv3 unsuited for IPP/JMP Notificiations >Date: Sun, 22 Mar 1998 14:56:06 PST > >There two questions that have yet to be answered. > >You've repeatedly stated that SNMPv3 is not intended for "very many >notification clients". I would like to hear a technical analysis of why >you think this is the case. IEM> Because the SNMPv3 security depends on the distribution of shared secrets to EVERY managed system, but does NOT specify a Key Management Protocol. Because the SNMPv3 Target and Notification MIBs have highly inefficient string indices, placing a significant burden on ALL managed systems. For ACTIVE management (not just passive monitoring) of key infrastructure (routers, switches, hubs, etc), SNMPv3 may turn out to be quite successful in the marketplace, but deployment will undoubtedly be sporadic and interworking problems will be common. >Also, I think its VERY unrealistic that an embedded device will have to >manage "several hundred" client notification requests. If every client >can specify a totally different object set to be sent along with each >notification, then I don't think this is realistic for embedded devices. >If you have a defined trap/notification, with a specific list of objects >that are returned, then a notification originator only has to keep track >of transport domains and addresses, not every combination of object sets >that "possibly hundreds of notification clients" might want to know >about. IEM> Xerox (like IBM, and various other printer vendors) builds VERY big production printing systems (which may cost over a million dollars each). The SNMPv1 framework defines 6 different important traps; each interface MIB (Ethernet, TokenRing, etc) defines several more traps; the Printer MIB defines one trap; the PWG Job Monitoring MIB will (hopefully) define one or several (job- vs document-level) traps; the XCMI (Xerox Common Mgmt Interface) suite of 14 MIBs defines 16 different traps. Xerox clients do NOT register promiscuously for ALL traps - they pick and choose, according to their end-user preferences or roles (operators and system administrators have different interests and needs, for example). VERY lightweight trap registration is a necessity for the printer industry! >I don't think SNMPv3 is heavyweight. It's designed be implemented in >everything from $300 managed 100Mbit hubs, all the way to enterprise ATM >switches. And I think whatever solution we come up with will have to >have the capability to support a distributed event notification system, >similar to the way SENSE and other distributed notification mechanisms >remove the burden from individual embedded printers from having to keep >up with the entire world of notifications. IEM> But, your examples are all of infrastructure (intermediate-systems), not printers, scanners, and other end-systems. Managing a hub or router has essentially nothing in common with managing end-systems, except that they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to be widely deployed for at least the next three years - look at the deployment track record of SNMPv2! No vendor can tell their customers that they can't manage their printers until they deploy (largely non-existant) new enterprise open management systems (CA Unicenter, Tivoli TME, HP OpenView, Sun Solstice, etc) that have support for SNMPv3 (some of those that I just mentioned don't have support for SNMPv2, yet). Xerox research has found that many customers HATE to be told that "this product just requires a few little server applications." Elegant distributed event notification schemes like SENSE are very unpopular with Xerox product planners and marketers (and customers). Perhaps your customers haven't been bitten by unstable NetWare NLMs or NT server applications? [Jay, I personally think SENSE is good stuff - but technical excellence isn't the only or even major factor in the deployment of technology.] >----------------------------------------------------------------------< From jkm at underscore.com Mon Mar 23 10:26:43 1998 From: jkm at underscore.com (Jay Martin) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <9803230037.AA15969@snorkel.eso.mc.xerox.com> Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a simple > embedded device to maintain notification info for hundreds of clients. I agree 110%. That fundamental belief is one of the most critical assumptions for which SENSE was designed. Namely, require the managed entity (ie, a printer) to provide minimal scalability for key services (ie, just a few simultaneous client accesses), then route that information into a generalized client/server system with a very high degree of scalability. ...jay ---------------------------------------------------------------------- -- JK Martin | Email: jkm@underscore.com -- -- Underscore, Inc. | Voice: (603) 889-7000 -- -- 41C Sagamore Park Road | Fax: (603) 889-2699 -- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com -- ---------------------------------------------------------------------- From cmanros at cp10.es.xerox.com Mon Mar 23 13:38:27 1998 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:00:15 2009 Subject: JMP> NOT - Is SNMPv3 suitable for IPP Notifications? Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> All, We have had a rather intensive debate between Randy, who first proposed that we might want to use SNMPv3 traps or informs for IPP notifications, and Ira, who thinks that the whole idea is wrong. With the exception of Jay's comments earlier today, it has been very quiet from the rest of the group on this subject. Are there any other views on the subject? Do you support one or the other combattants' views? If all we will be hearing is arguments between mainly two people with diametrically opposite views, we are not going to archieve anything. We are supposed to discuss this next week in the IETF in LA and it would be nice to have a little better understanding of where the group stands in this debate by then. Should we abandon SNMPv3 as a candidate for IPP notifications and concentrate our efforts on a new or different solution? Please give more feedback to the DL. Carl-Uno Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From harryl at us.ibm.com Mon Mar 23 13:54:01 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica In-Reply-To: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica> Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> I response to Ira' comment... > IEM> But, your examples are all of infrastructure (intermediate-syste= ms), > not printers, scanners, and other end-systems. Managing a hub or rou= ter > has essentially nothing in common with managing end-systems, except t= hat > they use a common protocol - SNMPv1, NOT SNMPv3, which is unlikely to= be > widely deployed for at least the next three years - look at the deplo= yment We (PWG) crossed the "using SNMP to manage printers" question long ago.= Some people have never been comfortable with it but no one can deny we did. = To some degree, one can argue that every network element is part of it's infrastructure. That's pretty much how I believe we got where we are. I= 'm not saying it's right or wrong. I've just been trying to make good use of i= t rather than judge it or wish for something different. Also, I don't believe we can predict SNMPv3 rollout based on V2 lag. SN= MPv2 had a goory history - so bad that many chose not to implement. I view SNMPv= 3 as the answer to the v2 problem, not a repeat of it. Harry Lewis - IBM Printing Systems = From harryl at us.ibm.com Mon Mar 23 14:15:11 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica In-Reply-To: Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifica> Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> I also agree... (its not realistic for a simple embedded device to mai= ntain notification info for hundreds of clients). But, this does not mean tha= t the embedded Device should never be able to handle notification to multiple= clients. There may be more than one "notification server", or some smal= ler scale networks using peer-to-peer printing without a notification serve= r. Yes, the embedded device will ultimately limit the number of notificati= on hosts it can service, but (as I presented in Austin) I feel 16 - 32 is not unreasonable for many "network printers". Harry Lewis - IBM Printing Systems owner-sense@pwg.org on 03/23/98 08:33:19 AM Please respond to owner-sense@pwg.org To: rturner@sharplabs.com cc: sense@pwg.org, jmp@pwg.org, ipp@pwg.org Subject: SENSE> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notification Turner, Randy wrote: > I will reiterate my belief that I don't think its realistic for a sim= ple > embedded device to maintain notification info for hundreds of clients= From paulmo at microsoft.com Mon Mar 23 14:42:56 1998 From: paulmo at microsoft.com (Paul Moore) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Message-ID: <3.0.1.32.19980323103827.009c1280@garfield> Some time since I aired my views on this. I think we should make IPP notifications a mechanism whereby a client can request that a notification be sent to it via any mechanism. That is to say - the notification itself is sent any way you like and is not part of IPP. IPP merely provides the means for the client to request that this be done. We might want to define some standard optional mechanisms (email being the obvious one). All notifications are optional. The IPP Model also needs to define what events are notification candidates and what they mean. The IPP request indicates which events it wants notification on, what mechanism to use, any parameters associated with that mechanism (email address) and maybe message content. The mechanisms available should be something that is queryable (get printer attributes). There is a separate thing that deals with device level alerts and events - along with robust data transmission, etc. etc. My thoughts on that topic have already been aired! > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 10:38 AM > To: ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > All, > > We have had a rather intensive debate between Randy, who first > proposed that we might want to use SNMPv3 traps or informs for > IPP notifications, and Ira, who thinks that the whole idea is > wrong. > > With the exception of Jay's comments earlier today, it has been > very quiet from the rest of the group on this subject. Are there > any other views on the subject? Do you support one or the other > combattants' views? > > If all we will be hearing is arguments between mainly two people > with diametrically opposite views, we are not going to archieve > anything. > > We are supposed to discuss this next week in the IETF in LA and > it would be nice to have a little better understanding of where > the group stands in this debate by then. Should we abandon SNMPv3 > as a candidate for IPP notifications and concentrate our efforts > on a new or different solution? > > Please give more feedback to the DL. > > Carl-Uno > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From cmanros at cp10.es.xerox.com Mon Mar 23 16:10:02 1998 From: cmanros at cp10.es.xerox.com (Carl-Uno Manros) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? In-Reply-To: <5CEA8663F24DD111A96100805FFE6587030BC3B2@red-msg-51.dns.mi> Message-ID: <3.0.1.32.19980323131002.00ceac30@garfield> Paul, As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email. There has been some interesting discussion lately in the IFAX group about their intended use of MDNs for notifications over email. Those seem to indicate that implementation and actual use of MDNs in email is likely to be a very slow process... Carl-Uno At 11:42 AM 3/23/98 PST, Paul Moore wrote: >Some time since I aired my views on this. > >I think we should make IPP notifications a mechanism whereby a client can >request that a notification be sent to it via any mechanism. > >That is to say - the notification itself is sent any way you like and is not >part of IPP. IPP merely provides the means for the client to request that >this be done. > >We might want to define some standard optional mechanisms (email being the >obvious one). All notifications are optional. > >The IPP Model also needs to define what events are notification candidates >and what they mean. > >The IPP request indicates which events it wants notification on, what >mechanism to use, any parameters associated with that mechanism (email >address) and maybe message content. > >The mechanisms available should be something that is queryable (get printer >attributes). > >There is a separate thing that deals with device level alerts and events - >along with robust data transmission, etc. etc. My thoughts on that topic >have already been aired! > >> -----Original Message----- >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] >> Sent: Monday, March 23, 1998 10:38 AM >> To: ipp@pwg.org >> Cc: jmp@pwg.org; sense@pwg.org >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? >> >> All, >> >> We have had a rather intensive debate between Randy, who first >> proposed that we might want to use SNMPv3 traps or informs for >> IPP notifications, and Ira, who thinks that the whole idea is >> wrong. >> >> With the exception of Jay's comments earlier today, it has been >> very quiet from the rest of the group on this subject. Are there >> any other views on the subject? Do you support one or the other >> combattants' views? >> >> If all we will be hearing is arguments between mainly two people >> with diametrically opposite views, we are not going to archieve >> anything. >> >> We are supposed to discuss this next week in the IETF in LA and >> it would be nice to have a little better understanding of where >> the group stands in this debate by then. Should we abandon SNMPv3 >> as a candidate for IPP notifications and concentrate our efforts >> on a new or different solution? >> >> Please give more feedback to the DL. >> >> Carl-Uno >> >> >> Carl-Uno Manros >> Principal Engineer - Advanced Printing Standards - Xerox Corporation >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 >> Phone +1-310-333 8273, Fax +1-310-333 5514 >> Email: manros@cp10.es.xerox.com > > Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From paulmo at microsoft.com Mon Mar 23 16:29:20 1998 From: paulmo at microsoft.com (Paul Moore) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? Message-ID: <3.0.1.32.19980323131002.00ceac30@garfield> If this is the case "As far as I am aware, we seem to have agreements on most of the points in your message. The area in which there is still debate is for a delivery mechanism, that can send out notifications more quickly than with email." Then why is there a discussion? I can use anything I like for notifications. I cannot see why SNMP appears in this discussion. If a system wants to use SNMP to get events from a device then this is already possible - it has nothing to do with IPP. What IPP needs is end user focussed stuff (pagers, email, etc.). Faster than email would be the network native messenger service (SMB Net Send for example). > -----Original Message----- > From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > Sent: Monday, March 23, 1998 1:10 PM > To: Paul Moore; ipp@pwg.org > Cc: jmp@pwg.org; sense@pwg.org > Subject: RE: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > > Paul, > > As far as I am aware, we seem to have agreements on most of the points in > your message. The area in which there is still debate is for a delivery > mechanism, that can send out notifications more quickly than with email. > > There has been some interesting discussion lately in the IFAX group about > their intended use of MDNs for notifications over email. Those seem to > indicate that implementation and actual use of MDNs in email is likely to > be a very slow process... > > Carl-Uno > > > At 11:42 AM 3/23/98 PST, Paul Moore wrote: > >Some time since I aired my views on this. > > > >I think we should make IPP notifications a mechanism whereby a client can > >request that a notification be sent to it via any mechanism. > > > >That is to say - the notification itself is sent any way you like and is > not > >part of IPP. IPP merely provides the means for the client to request that > >this be done. > > > >We might want to define some standard optional mechanisms (email being > the > >obvious one). All notifications are optional. > > > >The IPP Model also needs to define what events are notification > candidates > >and what they mean. > > > >The IPP request indicates which events it wants notification on, what > >mechanism to use, any parameters associated with that mechanism (email > >address) and maybe message content. > > > >The mechanisms available should be something that is queryable (get > printer > >attributes). > > > >There is a separate thing that deals with device level alerts and events > - > >along with robust data transmission, etc. etc. My thoughts on that topic > >have already been aired! > > > >> -----Original Message----- > >> From: Carl-Uno Manros [SMTP:cmanros@cp10.es.xerox.com] > >> Sent: Monday, March 23, 1998 10:38 AM > >> To: ipp@pwg.org > >> Cc: jmp@pwg.org; sense@pwg.org > >> Subject: IPP> NOT - Is SNMPv3 suitable for IPP Notifications? > >> > >> All, > >> > >> We have had a rather intensive debate between Randy, who first > >> proposed that we might want to use SNMPv3 traps or informs for > >> IPP notifications, and Ira, who thinks that the whole idea is > >> wrong. > >> > >> With the exception of Jay's comments earlier today, it has been > >> very quiet from the rest of the group on this subject. Are there > >> any other views on the subject? Do you support one or the other > >> combattants' views? > >> > >> If all we will be hearing is arguments between mainly two people > >> with diametrically opposite views, we are not going to archieve > >> anything. > >> > >> We are supposed to discuss this next week in the IETF in LA and > >> it would be nice to have a little better understanding of where > >> the group stands in this debate by then. Should we abandon SNMPv3 > >> as a candidate for IPP notifications and concentrate our efforts > >> on a new or different solution? > >> > >> Please give more feedback to the DL. > >> > >> Carl-Uno > >> > >> > >> Carl-Uno Manros > >> Principal Engineer - Advanced Printing Standards - Xerox Corporation > >> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > >> Phone +1-310-333 8273, Fax +1-310-333 5514 > >> Email: manros@cp10.es.xerox.com > > > > > Carl-Uno Manros > Principal Engineer - Advanced Printing Standards - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com From imcdonal at eso.mc.xerox.com Mon Mar 23 21:30:49 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? In-Reply-To: Message-ID: <9803240230.AA16432@snorkel.eso.mc.xerox.com> Hi Randy, Harry, Paul, Jay, et al, I concede all points. I got dragooned into stating my technical objections to the scalability of the SNMPv3 trap registration mechanisms. The discussion has wandered off completely into the merits of the SNMPv3 protocol itself, which is irrelevant. I never wanted to start this thread. I hereby withdraw from it. I'll watch with interest what you folks decide on. Cheers, - Ira McDonald (High North) PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. From rturner at sharplabs.com Mon Mar 23 23:34:02 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> RE: IPP> Re: NOT - Is SNMPv3 suitable for IPP Notifications? In-Reply-To: Re: NOT - Is SNMPv3 suitable for IPP Notifications?> Message-ID: <9803240230.AA16432@snorkel.eso.mc.xerox.com> ..snip.. PS - In a few weeks, my wife Nancy and I fly off to Scotland for five weeks of walking and visiting gardens (MUCH more rewarding than computer industry standards work). We'll be back on our farm in Grand Marais, Michigan around Wednesday (20 May). Good luck with the IESG on IPP/1.0. Need someone to carry your luggage? Randy From walker at dazel.com Tue Mar 24 10:12:23 1998 From: walker at dazel.com (James Walker) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <3517CD57.28B24665@dazel.com> Jay Martin wrote: > > Turner, Randy wrote: > > > I will reiterate my belief that I don't think its realistic for a simple > > embedded device to maintain notification info for hundreds of clients. > > I agree 110%. That fundamental belief is one of the most critical > assumptions for which SENSE was designed. Namely, require the > managed entity (ie, a printer) to provide minimal scalability for > key services (ie, just a few simultaneous client accesses), then > route that information into a generalized client/server system > with a very high degree of scalability. Well, here we go again... Is it just me, or are we running into the embedded printer requirements versus the print server requirements. If we are talking about IPP, the host to device protocol, then I agree that the device need only support a limited number of notification clients. If we are talking about IPP, the print client to server protocol, then I believe that print server ought to be able to scale to 100's, even 1000's, of clients. ...walker -- Jim Walker System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX From harryl at us.ibm.com Tue Mar 24 11:34:05 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: IPP> Re: SNMPv3 unsuited for IPP/JMP Notifications In-Reply-To: Re: SNMPv3 unsuited for IPP/JMP Notifications> Message-ID: <3517CD57.28B24665@dazel.com> Well, yes, it gets pretty confusing... >Well, here we go again... > >Is it just me, or are we running into the embedded printer requirement= s >versus the print server requirements. If we are talking about IPP, th= e >host to device protocol, then I agree that the device need only suppor= t >a limited number of notification clients. If we are talking about IPP= , >the print client to server protocol, then I believe that print server >ought to be able to scale to 100's, even 1000's, of clients. > >...walker Because we're talking less about IPP and more about a notification serv= ice where, as a potential ubiquitous print submission protocol, IPP needs a= mechanism for registering clients for notifications, regardless of the scalability of the notification server I think we need to look at notification services both from the limitati= ons of an embedded device (where most notifications will originate), AND from = the point of view of a robust server implementation (like SENSE). The devic= e is not likely to accept the notion of give me e-mail on this message, pager fr= om noon-2pm and fog horn after dark. Oh, and I'd like specifically, and ON= LY, the following content with that notice. But, I'm hearing that we wish to co= nsider all this flexibility (and more) in our design. If we break notification into "stages"... the "device originated notifi= cation" and the "server based notification"... I think it is likely that typica= l client-server-device breakpoints will result in several registered host= s at the device. It is also possible to create a limited peer-to-peer printing s= ystem with no notification server where print clients register directly with = the device. It is also possible to create a notification server that simply= polls the device, eliminating the need for a device notification protocol or registration scheme. Since, as Jim points out, we really are talking about (at least) two st= ages of notification, we should be careful to indicate which part of the proble= m our recommendation is addressing. Harry Lewis - IBM Printing Systems = From rturner at sharplabs.com Tue Mar 24 21:32:34 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> Portland Attendance... Message-ID: <3517CD57.28B24665@dazel.com> We maybe setting a new record for JMP/FIN attendance. I have 17 RSVPs for the Friday meeting, with 2 more possibilities on the horizon. I currently have a smaller room reserved for that day...I hope I didn't screw up. Randy From imcdonal at eso.mc.xerox.com Wed Mar 25 09:47:11 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Portland Attendance... In-Reply-To: Portland Attendance...> Message-ID: <9803251447.AA17311@snorkel.eso.mc.xerox.com> Hi Randy, As someone who can never attend the PWG monthly meetings in person, I find that high registration for JMP/FIN rather discouraging, given the virtual silence on their mailing lists for the last month. It seems that PWG members would much rather do all their work face-to-face instead of discussing issues on the mailing lists. Leaves the rest of us out of the picture. Oh well, - Ira McDonald -------------------------------------------------------------------- [Randy's note] Return-Path: Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1) id AA17225; Tue, 24 Mar 98 21:44:50 EST Received: from alpha.xerox.com by zombi (4.1/SMI-4.1) id AA10666; Tue, 24 Mar 98 21:38:49 EST Received: from lists.underscore.com ([199.125.85.30]) by alpha.xerox.com with SMTP id <52287(3)>; Tue, 24 Mar 1998 18:38:26 PST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA02518 for ; Tue, 24 Mar 1998 21:35:00 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 24 Mar 1998 21:34:07 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA02387 for jmp-outgoing; Tue, 24 Mar 1998 21:32:43 -0500 (EST) Message-Id: From: "Turner, Randy" To: "'jmp@pwg.org'" Subject: JMP> Portland Attendance... Date: Tue, 24 Mar 1998 18:32:34 PST X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: jmp-owner@pwg.org Status: R We maybe setting a new record for JMP/FIN attendance. I have 17 RSVPs for the Friday meeting, with 2 more possibilities on the horizon. I currently have a smaller room reserved for that day...I hope I didn't screw up. Randy From harryl at us.ibm.com Wed Mar 25 10:15:33 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:15 2009 Subject: JMP> Portland Attendance... In-Reply-To: Portland Attendance...> Message-ID: <9803251447.AA17311@snorkel.eso.mc.xerox.com> Ira... let's not discourage attendance!! ;-) Your participation via e-mail and phone has been VERY valuable, Ira... = it's unfortunate that you haven't been able to attend the face-to-face meeti= ngs, but we'll take your input any way we can. We try to have a process which is= effective at discussing and resolving issues and moving the standards f= orward regardless of the constraints of our members... it's not always ideal. = I am guilty of falling behind and only recently catching up on the excellent= discussion between you and Randy on SNMPv3 - one you'd think I would be= right on top of. The way it works for me is, when I've carved time out for th= e meeting I can focus on standards. When I get back in the office I've go= t REAL work, including that which piled up while I was away ;-). I'm sure it's= no different for you, or any of us, when we address these broader issues..= From hastings at cp10.es.xerox.com Tue Mar 31 12:07:51 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> Why hasn't the PWG Job Monitoring MIB been published as an RFC? Message-ID: <3.0.1.32.19980331090751.011d4ac0@garfield> Anyone heard from the RFC Editor about our request to publish the approved PWG Job Monitoring MIB standard as an Informational RFC? Thanks, Tom From lpyoung at lexmark.com Tue Mar 31 14:03:25 1998 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 14:00:15 2009 Subject: JMP> Why hasn't the PWG Job Monitoring MIB been published as In-Reply-To: Why hasn't the PWG Job Monitoring MIB been published as> Message-ID: <199803311905.AA26305@interlock2.lexmark.com> Tom, We are checking on it but have not heard anything back yet. Lloyd -------------- Reply separator ------------- To: jmp%pwg.org@interlock.lexmark.com cc: (bcc: Lloyd Young) Subject: JMP> Why hasn't the PWG Job Monitoring MIB been published as an RFC? Anyone heard from the RFC Editor about our request to publish the approved PWG Job Monitoring MIB standard as an Informational RFC? Thanks, Tom From bpenteco at boi.hp.com Tue Mar 31 19:01:34 1998 From: bpenteco at boi.hp.com (Bob Pentecost) Date: Wed May 6 14:00:15 2009 Subject: JMP> HP representative to PWG Message-ID: <199803311905.AA26305@interlock2.lexmark.com> When I announced my departure from the PWG at the Austin meeting, I had replacements for nearly all of my PWG activities. The areas not covered were the Printer MIB and Job Monitoring MIB. That situation is now resolved. Matt Young, whom I've worked with for several years, will be taking over the Printer MIB and Job Monitoring MIB. Matt has implemented Printer MIB as well as proprietary HP MIB objects for the LaserJet 5Si, 4000 and 5000 printers. Matt is looking forward to working in the standards development arena, and is particularly interested in a trip to Hawaii. :-) Please welcome Matt to the group and feel free to ask him the tough questions as you asked me! Bob Pentecost HP From hastings at cp10.es.xerox.com Tue Mar 31 19:29:49 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> How would someone find out the PWG approved the Job Monitoring Message-ID: <3.0.1.32.19980331162949.0125a100@garfield> Someone here at Xerox asked how they would know that the PWG had approved the PWG Job Monitoring MIB as a PWG standard? Should the PWG make a Press Release? Should we update the PWG web page to announce that and point to the document? Tom From harryl at us.ibm.com Wed Apr 1 12:19:47 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:15 2009 Subject: JMP> How would someone find out the PWG approved the Job In-Reply-To: How would someone find out the PWG approved the Job> Message-ID: <3.0.1.32.19980331162949.0125a100@garfield> I have similar concerns that the Job MIB is languishing in a no man's l= and right now. I think the process should be something like... 1. Internally (PWG) develop and approve - DONE 2. Submit to IETF as informational - DONE 3. Receive some sort of IETF recognition (RFC number), which shouldn't = require much effort on the IETF's part since it's informational 4. "Announce" the first "official" PWG standard, referencing the RFC, indicating there are more to come - establishing more independent recog= nition of PWG as an industry standards group. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 03/31/98 05:34:51 PM Please respond to jmp-owner@pwg.org To: jmp@pwg.org cc: Subject: JMP> How would someone find out the PWG approved the Job Mon Someone here at Xerox asked how they would know that the PWG had approved the PWG Job Monitoring MIB as a PWG standard? Should the PWG make a Press Release? Should we update the PWG web page to announce that and point to the document? Tom = From rbergma at dpc.com Thu Apr 2 11:27:05 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> SNMP Notifications and Registration Methods Agenda Message-ID: <3.0.1.32.19980331162949.0125a100@garfield> Carl-Uno has agreed to provide a 2-3 hour slot next Thursday to discuss SNMP notifications and registration as applicable to both IPP and the Job Monitoring MIB. There is considerable interest in the IPP group on this subject, since it appears that SNMP traps and/or informs could be one of the possible notification methods for IPP. Randy did a very good job in Austin of providing background on SNMPv3 and I would like to further examine this subject and reach a general consensus as to the direction. The meeting agenda will consist of two primary topics. I. Trap/Inform conditions: The JMP group has defined 11 conditions that could generate a trap/inform condition. I would like to quickly review these with the IPP group to insure that this list is adequate. (If time permits, we will review Tom Hastings proposed definitions for these items.) 1. Start of job 2. Job completion 3. Job aborted 4. Job canceled 5. Job progress, sheets stacked 6. Job progress, copy completed 7. Job received 8. Job hold notification 9. Job release notification 10. Print deadline exceeded 11. Job accounting information expired II. Registration methods: This is presently the most controversial part of the project and I expect will occupy the majority of the meeting. To prepare for the meeting, I suggest that everyone review the SNMPv3 documents (RFCs 2271 to 2275) and the Job Async Monitoring MIB (Joe Filion, and Ira McDonald at ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jam_v010.txt). I can think of four possible alternatives: 1. Use the SNMPv3 registration MIBS. 2. Use the Job Async Monitoring MIB registration. 3. Create a hybrid with the best of both and maybe new ideas. 4. Send SNMP into the world of deprecation, (and never to be heard from again). See you in Portland, Ron Bergman Dataproducts Corp. From imcdonal at eso.mc.xerox.com Sun Apr 5 12:25:04 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:15 2009 Subject: JMP> Posted JAM MIB v0.20 - 5 April 1998 Message-ID: <9804051625.AA20490@snorkel.eso.mc.xerox.com> Copies To: jmp@pwg.org hastings@cp10.es.xerox.com Joe_Filion@mc.xerox.com imcdonal@eso.mc.xerox.com Hi folks, Sunday (5 April 1998) In response to Ron Bergman's recent agenda topic on Notifications for the JMP session at the PWG monthly meeting, I just posted the text of a revised (documentation only) JAM MIB written by Joe Filion (Xerox) and Ira McDonald (High North) to the PWG FTP server in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions Cheers, - Ira McDonald High North Inc ------------------------------------------------------------------------ SYNOPSIS ------------------------------------------------------------------------ This document specifies the Job Async Monitoring (JAM) MIB, an individual contribution to the Job Monitoring Project (JMP) of the Printer Working Group (PWG), a work-in-progress MIB module for the entire printer industry, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The JAM MIB specifies a lightweight SNMP trap registration mechanism for end-user clients, management stations, and management proxies. This SNMP trap registration mechanism is SNMP protocol version independent. This SNMP trap registration mechanism is security scheme independent. The JAM MIB is a companion to the PWG Job Monitoring MIB and the IETF/PWG Printer MIB (published separately). The JAM MIB is UNENCUMBERED by any patents pending or granted or other intellectual property considerations. ------------------------------------------------------------------------ FILES ------------------------------------------------------------------------ These files are in 'ftp://ftp.pwg.org/pub/pwg/jmp/contributions': rel_0405.txt - this release note jam_v020.txt - Job Async Monitoring MIB v0.20 - text w/ formfeeds jam_v020.mib - Job Async Monitoring MIB v0.20 - ASN.1 source of MIB From hastings at cp10.es.xerox.com Mon Apr 6 20:17:28 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> Alignment of media consumed in Printer MIB & Job MIB with IPP Message-ID: <3.0.1.32.19980406171728.00c67580@garfield> Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB=20 for the media names that can be used, such as 'iso-a4-white', and=20 'na-letter-white'.=20 Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names:=20 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from=20 Appendix B can be used in addition to media names from Appendix C in the=20 Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence=20 between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::=3D { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type=20 AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the=20 job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets=20 AND=20 OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. =20 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From bogus@does.not.exist.com Tue Apr 7 01:11:36 1998 From: bogus@does.not.exist.com () Date: Wed May 6 14:00:15 2009 Subject: No subject Message-ID: <> For what it is worth, the document draft-ietf-connect-media-features-00.txt attempts to use the 'printer mib' for the proper enumeration of paper sizes. If you think it's better to set paper size in terms of actual sizes rather than an enumeration, we should track it in media features. Larry -- http://www.parc.xerox.com/masinter -----Original Message----- From: ipp-owner@pwg.org [mailto:ipp-owner@pwg.org]On Behalf Of Tom Hastings Sent: Monday, April 06, 1998 5:17 PM To: pmp@pwg.org; jmp@pwg.org Cc: ipp@pwg.org Subject: IPP> Alignment of media consumed in Printer MIB & Job MIB with IPP to allow media size names Here is an issue that crosses the Printer MIB and the Job MIB. Currently, the Job Monitoring MIB has an attribute that records the media consumed (mediumConsumed) by a job. It cites the Printer MIB for the media names that can be used, such as 'iso-a4-white', and 'na-letter-white'. Currently, the names for media sizes ('iso-a4' and 'na-letter') are not in that list in the Printer MIB. Often a device only knows the size, not the name of the media in its trays. Printer MIB Appendix C has the ISO DPA media names: 'iso-a4-white' etc. Printer MIB Appendix B has the ISO DPA media size names: 'iso-a4', etc, but the Printer MIB prtInputMediaName object only refers to Appendix C. However, in IPP, we included media names and media sizes in the "media" attribute. See IPP Appendix C. ISSUE 1 for the Printer MIB: Should we add to the Printer MIB specification that media size names from Appendix B can be used in addition to media names from Appendix C in the Printer MIB? ISSUE 2 for the PWG Job Monitoring MIB: Then the PWG Job Monitoring MIB would be able to use either media names or media size names in its mediumConsumed attribute to get coherence between all three of our standards. Or should we add to the PWG Job Monitoring MIB mediumConsumed a reference to IPP as well (as is done for mediumRequested) so that media size names could be used in the Job Monitoring MIB, even if not in the Printer MIB? The current Printer MIB definition is: prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the media contained in this input sub- unit; This description is intended for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g. prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType). An example would be 'legal tender bond paper'." REFERENCE "See Appendix C, 'Media Names'." ::= { prtInputEntry 12 } The current PWG Job Monitoring MIB specifications for "mediumRequested" and mediumConsumed" are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets AND OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. The current IPP "media" description is: 4.2.11 media (type4 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input-trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer SHALL merge with the document data as its prints each page. Standard values are (taken from ISO DPA and the Printer MIB) and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.5. From lpyoung at lexmark.com Tue Apr 14 13:30:26 1998 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 14:00:15 2009 Subject: JMP> Status of Job Monitoring MIB Message-ID: <199804141731.AA27635@interlock2.lexmark.com> Chris checked with the RFC editor to determine the status of the Job Monitoring MIB. The answer she got back was that there is a significant backlog in the editor's shop. It is taken much longer than usual to publish RFC's. Regards, Lloyd ------------------------------------------------------------ Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C08L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740 From hastings at cp10.es.xerox.com Tue Apr 14 12:28:24 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> Registration Last Call: mediumTypeConsumed(174) and Message-ID: <3.0.1.32.19980414092824.011464c0@garfield> I have posted the following registration proposals for a two week Last Call for use with the Job Monitoring MIB. We reviewed this proposal at the PWG meeting on Friday, 10 April 1998, and agreed to send it out for a two-week Last Call as the final step in approving these two attributes, medimTypeConsumed(174) and mediumSizeConsumed(175), as registered attributes for use with the PWG Job Monitoring MIB v1.0. ftp://ftp.pwg.org/pub/pwg/jmp/proposed-registrations/001-medium-x-consumed.doc ftp://ftp.pwg.org/pub/pwg/jmp/proposed-registrations/001-medium-x-consumed.pdf ftp://ftp.pwg.org/pub/pwg/jmp/proposed-registrations/001-medium-x-consumed.txt If and when they are approved, I, as editor, will move them (with any updates) from the above directory to: ftp://ftp.pwg.org/pub/pwg/jmp/approved-registrations/ As editor, we agreed that I will also update a version of the Job Monitoring MIB specification (.doc, .pdf, .txt, and .mib) to show all approved registrations and clarifications. This updated version of the Job Monitoring MIB will show all changes from version 1.0 and will have a change history which summarizes each change, so that there is one document that contains all approved clarifications and registrations. (Clarifications will follow the same approval process as registrations.) The last call will terminate on: Monday, April 27, 1998, 5:00pm PDT. Tom Subj: JMP proposal to register mediumTypeConsumed and mediumSizeConsumed From: Tom Hastings Date: 4/10/98 File: 001-medium-x-consumed.doc Here is a proposal to register two new accounting attributes to be used with the approved PWG Job Monitoring MIB standard. These new attributes count media by medium type name and medium size name. The current PWG Job Monitoring MIB specifications for "mediumRequested" (medium type enum, medium name and medium size name) and mediumConsumed" (medium name) are: mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the job. NOTE - The name (JmJobStringTC) values correspond to the prtInputMediaName object in the Printer MIB [print-mib] and the values of the IPP 'media' attribute. mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets AND OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib]. 1 I propose adding two additional attributes to record media type consumed and media size consumed: mediumTypeConsumed(174), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets of the indicated medium type that has been consumed so far whether those sheets have been processed on one side or on both AND OCTETS: MULTI-ROW: the name of that medium type. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The type name (JmJobStringTC) values correspond to the type name values of the prtInputMediaType object in the Printer MIB [print-mib]. Values are: 'stationery', 'transparency', 'envelope', etc. These medium type names correspond to the enum values of JmMediumTypeTC used in the mediumRequested attribute. mediumSizeConsumed(175), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets of the indicated medium size that has been consumed so far whether those sheets have been processed on one side or on both AND OCTETS: MULTI-ROW: the name of that medium size. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The size name (JmJobStringTC) values correspond to the size name values in the Printer MIB [print-mib] Appendix B. Values are: 'letter', 'a', 'iso-a4', 'jis-b4', etc. 2 From jds at underscore.com Wed Apr 15 10:08:48 1998 From: jds at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:00:15 2009 Subject: JMP> Status of Job Monitoring MIB In-Reply-To: Status of Job Monitoring MIB> Message-ID: <3.0.1.32.19980414092824.011464c0@garfield> [NOTICE to users of Lotus notes... DO NOT USE "REPLY" -- it is broken in that it incorrectly addresses the reply to the message 'Sender' (in this case the list owner) rather than the proper 'From' address. /Jeff] ------------------------------------------------------------------------ Admittedly a naive question... but, to what degree is an "RFC editor" involved when the submission is informational? I don't live on the edge of my seat waiting for each new RFC (just the Job and Printer MIBs!), but didn't I see one or two rather "cute" one's issue lately? I presume these wee part of the backlog? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 04/14/98 11:33:56 AM Please respond to jmp-owner@pwg.org To: jmp@pwg.org cc: Subject: JMP> Status of Job Monitoring MIB Chris checked with the RFC editor to determine the status of the Job Monitoring MIB. The answer she got back was that there is a significant backlog in the editor's shop. It is taken much longer than usual to publish RFC's. Regards, Lloyd ------------------------------------------------------------ Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C08L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740 From lpyoung at lexmark.com Wed Apr 15 10:55:05 1998 From: lpyoung at lexmark.com (lpyoung@lexmark.com) Date: Wed May 6 14:00:15 2009 Subject: JMP> Status of Job Monitoring MIB In-Reply-To: Status of Job Monitoring MIB> Message-ID: <199804151455.AA16813@interlock2.lexmark.com> Harry, There is editorial work required in converting an internet-draft to an RFC (even an Informational RFC). This work can only be done by the RFC editors. According to the RFC editor department coordinator there has been a large influx of requests to issue RFCs and they are running behind. The Job MIB is a part of this backlog. Lloyd Please respond to harryl%us.ibm.com@interlock.lexmark.com To: jmp%pwg.org@interlock.lexmark.com cc: (bcc: Lloyd Young) Subject: Re: JMP> Status of Job Monitoring MIB [NOTICE to users of Lotus notes... DO NOT USE "REPLY" -- it is broken in that it incorrectly addresses the reply to the message 'Sender' (in this case the list owner) rather than the proper 'From' address. /Jeff] ------------------------------------------------------------------------ Admittedly a naive question... but, to what degree is an "RFC editor" involved when the submission is informational? I don't live on the edge of my seat waiting for each new RFC (just the Job and Printer MIBs!), but didn't I see one or two rather "cute" one's issue lately? I presume these wee part of the backlog? Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 04/14/98 11:33:56 AM Please respond to jmp-owner@pwg.org To: jmp@pwg.org cc: Subject: JMP> Status of Job Monitoring MIB Chris checked with the RFC editor to determine the status of the Job Monitoring MIB. The answer she got back was that there is a significant backlog in the editor's shop. It is taken much longer than usual to publish RFC's. Regards, Lloyd ------------------------------------------------------------ Lloyd Young Lexmark International, Inc. Senior Program Manager Dept. C08L/Bldg. 035-3 Strategic Alliances 740 New Circle Road NW internet: lpyoung@lexmark.com Lexington, KY 40550 Phone: (606) 232-5150 Fax: (606) 232-6740 From rturner at sharplabs.com Fri Apr 17 13:53:25 1998 From: rturner at sharplabs.com (Turner, Randy) Date: Wed May 6 14:00:15 2009 Subject: JMP> FW: I-D ACTION:draft-skreddy-enpreq-00.txt Message-ID: <199804151455.AA16813@interlock2.lexmark.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD6A29.BADD2360 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] Sent: Friday, April 17, 1998 7:28 AM Subject: I-D ACTION:draft-skreddy-enpreq-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Event Notification Protocol Author(s) : S. Reddy Filename : draft-skreddy-enpreq-00.txt Pages : 6 Date : 16-Apr-98 This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-skreddy-enpreq-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-skreddy-enpreq-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. <> ------ =_NextPart_000_01BD6A29.BADD2360 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Fri, 17 Apr 1998 10:53:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BD6A29.BADD2360" ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: text/plain ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: application/octet-stream; name="ATT03355.txt" Content-Disposition: attachment; filename="ATT03355.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980416102106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-skreddy-enpreq-00.txt ------ =_NextPart_002_01BD6A29.BADD2360 Content-Type: message/external-body; site="internet-drafts"; dir="draft-skreddy-enpreq-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BD6A29.BADD2360-- ------ =_NextPart_000_01BD6A29.BADD2360-- From hastings at cp10.es.xerox.com Fri Apr 24 17:58:19 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> MOD - Updated notification proposal posted Message-ID: <3.0.1.32.19980424145819.01298470@garfield> Harry and I have updated our IPP notification proposal based on the meeting consensus. Its available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf The .pdf version should be used to make comments using the line numbers. We'd like to discuss this at the IPP telecon Wed, April 29, 10-12 PDT. It also lists the event groupings and notification content for use with the Job Monitoring MIB. Thanks, Tom and Harry From hastings at cp10.es.xerox.com Tue May 5 16:47:31 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> MOD - Updtaed notification proposal, V0.3 for 5/6 telecon Message-ID: <3.0.1.32.19980505134731.0124b320@garfield> I've posted the updated notification white paper, V0.03. I've included the comments and agreements reached at the last telecon, 4/29/98. I checked the minutes as well as my notes. We'd like to discuss again at the 5/6/97 telecon. On terminology, I've included the terms from the requirements document. They are similar to the ones in Josh Cohen's notification I-D. Neither used the term "message". I've left the JMP stuff there as well, but put it inside [] so we can remove it when making an IPP I-D. The files are: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf Lets use the last file with line numbers for review at the telecon. Send any comments/issues ahead of time. There are a number of issues remaining that are highlighted. We should discuss them on the telecon, as well as any other issues that people have. Tom From hastings at cp10.es.xerox.com Wed May 13 17:23:45 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> MOD & PRO - IPP Event Notification, V0.05, posted Message-ID: <3.0.1.32.19980513142345.01196910@garfield> Scott, Harry, and I have finished our action item to incorporate the agreements from the Portland meeting into the IPP notification proposal. Its version 0.05. Thanks go to Ron Bergman and Devon Taylor (of Novell) for additional review. I'm posting it for discussion at the upcoming IPP meeting, in Washington, 5/20 - 5/21: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal-rev.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-event-notification-proposal.pdf Use the last one for making comments as it has line numbers. Please take the time to read the entire specification. We've seen it enough by now. Its grown to 50 pages, with the spec for the 'collection' attribute syntax included as an appendix as we agreed on the telecon. Is it ready to be made a first Internet-Draft? Please send any comments before the meeting (and bring your copy to the meeting). It also has the PWG Job Monitoring MIB (JMP) Notification Content (and 6 IPP Job object Description IPP attributes for event monitoring of job progress to align with the Job MIB). Here is the abstract and the summary from the paper: Event notifications for the IPP print protocol [and JMP] Version 0.05 The appendix has the full specification for the 'collection' attribute syntax, as agreed on our 5/6/98 telecon. [Items in square brackets relate to the PWG Standard Job Monitoring MIB [jmp-mib] trapping and will be removed when this document is made into an IPP Internet-Draft.] Status of this Memo This document is a PWG Working Draft. It is intended to become a first Internet-Draft when there is rough consensus that it is ready and then to proceed on the IETF standards track to be used with IPP/1.0. It is being developed under the charter for IPP/1.0 and meets the requirements in [req]. Abstract In IPP/1.0, the user can determine what is happening to submitted jobs by using the Get--Attributes and Get-Jobs operations to poll for results. This document describes an OPTIONAL extension to the IPP/1.0 Model document for subscribing for event notifications using IPP, but which are delivered over some other protocol, either by the IPP Printer object or by any notification service that the IPP Printer object implementation may employ. See [req] for the notification requirements. Two methods are provided for subscription for notification events: (1) as part of the job submission and (2) as a separate Subscribe-For-Event-Notifications operation. Both methods allow the requester to specify (1) about which event(s) to be notified, (2) which notification-recipient(s) are to receive the notification, (3) what content type is to be sent in the notification, and (4) which notification transport method is to be used. Both methods allow the requester to subscribe for job event groups, such as 'job-completion', and/or printer events, such as 'printer-errors'. The event notification subscription mechanism uses a new attribute syntax called a 'collection'. A 'collection' value is a set of attributes. See the Appendix of this document for the complete specification of the 'collection' attribute syntax. 1.1 Summary of the proposal for IPP Event Notification This paper proposes the following: 1. One OPTIONAL "job-notify" Operation attribute for use with the Print-Job, Print-URI, and Create-Job operation. The "job-notify" Operation attribute has an attribute syntax of '1setOf collection' (see Appendix) so that the client can request different events for different notification recipients for the same job. Each collection value SHALL contain the "notify-recipients" and MAY contain any of the following remaining member attributes with the indicated syntax and support by the IPP object if it supports the "job-notify" Operation attribute at all: Member attribute name syntax in request support ------------------- ---- ---------- ------ "notify-event-groups" 1setOf type2 keyword MAY mandatory "notify-recipients" 1setOf uri SHALL mandatory "notify-content-type" mimeMediaType MAY mandatory "notify-charset" charset MAY mandatory "notify-natural-language" naturalLanguage MAY optional "notify-additional-attributes" 1setOf keyword MAY optional 2. Two new OPTIONAL Subscribe-For-Event-Notifications and Unsubscribe-For-Event-Notifications operations on the Printer object. These operations are intended for operator/administrators and servers for long term subscription for Printer object events that are independent of job submission. The servers may be involved with (1) job submission to IPP Printer objects and/or (2) collecting accounting data using the event notification mechanism. An IPP Printer SHALL support both of these operations, if it supports either one. If an IPP Printer supports these operations, it SHALL also support the "job-notify" attribute in the create operations. 3. One "job-notify" Job object Description attribute which is populated with the collection value(s) supplied by the "job-notify" Operation attribute in a create operation. 4. Six Job object Description attributes for monitoring job progress at the sheet completed and collated document copy level to align with the PWG Job Monitoring MIB. 5. One new "printer-notify" Printer object Description attribute which is populated with the collection value supplied by the "printer-notify" Operation attribute in the Subscribe-For-Event-Notifications operation. Both attribute use the same collection as the "job-notify" Operation attribute. The "printer-notify" Printer Description attribute also has an additional "notify-subscription-id" member attribute which is an integer id for the subscription for use with the Unsubscribe-For-Event-Notification operation. 6. Six "xxx-supported" Printer object Description attributes that correspond to the six member attributes in the collection values of the "job-notify" and "printer-notify" Operation attributes. Tom Hastings From jeff at underscore.com Tue Jun 23 10:50:52 1998 From: jeff at underscore.com (Jeff Schnitzer) Date: Wed May 6 14:00:15 2009 Subject: JMP> Please ignore this test message. Message-ID: <3.0.1.32.19980513142345.01196910@garfield> Please ignore this test message. This message is being posted to verify that PWG mailing lists are public, per Keith Moore's mandate. Note that the Majordomo "who" command remains disabled. /Jeff Schnitzer --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- >To: wg-chairs@apps.ietf.org >Subject: mailing lists that don't allow outside posts >cc: moore@cs.utk.edu >From: Keith Moore >Date: Fri, 19 Jun 1998 13:23:39 PDT > >It's come to my attention that some of the WG mailing lists don't >allow posts from people who aren't on the list. > >This is not an acceptable policy for IETF WG lists. It's important to >allow people who aren't subscribed to the list to make suggestions >or ask questions. It's also important to allow cross-postings >between lists where a single topic is of interest to multiple >working groups. Finally, it unfairly penalizes against those >who use subaddresses. > >There are other ways of effectively blocking spam besides >blocking postings from non-subscribers. > >Lists that do this need to be fixed asap. > >Keith > From Stuart.Rowley at kyocera.com Wed Jul 1 12:12:28 1998 From: Stuart.Rowley at kyocera.com (Stuart Rowley) Date: Wed May 6 14:00:15 2009 Subject: JMP> How to compile Job MIB with OpenView Message-ID: <0004D502.@kyocera.com> Job MIBers, How can the Job MIB be compiled with HP OpenView? In the MIB document on page 18 it says: "This MIB, like the Printer MIB, is written following the subset of SMIv2 that can be supported by SMIv1 and SNMPv1 implementations." But while OpenView can compile the Printer MIB, it chokes on the Job MIB. Any ideas why OpenView will not compile the Job MIB? Thanks, Stuart --------------------------------------------------------------------- Stuart Rowley Kyocera Electronics, Inc. Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 stuart.rowley@kyocera.com Lafayette, CA 94549 925 299-7206 Fax: 925 299-2489 --------------------------------------------------------------------- From rbergma at dpc.com Wed Jul 1 12:22:30 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> How to compile Job MIB with OpenView In-Reply-To: <0004D502.@kyocera.com> Message-ID: Stuart, When I tried to compile a private MIB on Open View it didn't understand "enterprises". I had to add the following: internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } I don't know if all are required, as I added all three lines and didn't try to remove any after it was successful. Note that I have a four year old version of Open View, so your results may be different. Good luck :-) Ron Bergman Dataproducts Corp. On Wed, 1 Jul 1998, Stuart Rowley wrote: > Job MIBers, > > How can the Job MIB be compiled with HP OpenView? In the MIB document on > page 18 it says: > "This MIB, like the Printer MIB, is written following the subset of SMIv2 > that can be supported by SMIv1 and SNMPv1 implementations." > But while OpenView can compile the Printer MIB, it chokes on the Job MIB. > > Any ideas why OpenView will not compile the Job MIB? > > Thanks, > > Stuart > > --------------------------------------------------------------------- > Stuart Rowley Kyocera Electronics, Inc. > Network Product Development Mgr. 3675 Mt. Diablo Blvd. #105 > stuart.rowley@kyocera.com Lafayette, CA 94549 > 925 299-7206 Fax: 925 299-2489 > --------------------------------------------------------------------- > From hastings at cp10.es.xerox.com Thu Jul 2 01:33:46 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> White paper - proposal to add multi-function activity attributes Message-ID: <3.0.5.32.19980701223346.00a11ba0@garfield> I've uploaded a white paper that proposes about 30 attributes that are designed to be useful for multi-function systems, including printing, scaning, faxIn, faxOut, etc. It also gives more detailed accounting, as each different combination of accounting data is collected in a separate row, called an "activity". ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jmp-activity-accounting-01.doc ftp://ftp.pwg.org/pub/pwg/jmp/contributions/jmp-activity-accounting-01.pdf If approved, these attributes would be registered with the PWG as Job Monitoring MIB attributes. I propose to discuss these ideas at the JMP MIB meeting on Friday, July 10. I'll bring copies to the meeting. Its 19 pages long. Thanks, Tom From hastings at cp10.es.xerox.com Mon Jul 27 23:13:15 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: job mib feedback In-Reply-To: <199807271855.OAA19942@spot.cs.utk.edu> Message-ID: <3.0.5.32.19980727201315.017b3430@garfield> At 11:55 07/27/98 PDT, Keith Moore wrote: >Tom & Chris, > >The job mib was on the agenda for the IESG's Jul 16 telechat. >It was held up because of problems with the specification. >To wit: > >> It is on this weeks telechat agenda as a WG subission to go >> out as INFORMATIONAL RFC. Number 3 below is real serious. >> >> 1.I get 15 warnings about unused TCs. >> That is acceptable... but are they used elsewere? No, they are only used in this MIB. But they only appear as comments in the JmAttributeTypeTC. We have the case of a TC "using" the 15 TCs. We could add dummy used of these TCs, to make the warnings go away, but the "That is acceptable" sound like we don't really have to do that. >> In other words do you need to keep them? Yes, because an implementation does use the values. These TCs are the values of attributes that are of type enum. Attributes can also have integer values that count and/or octet strings that are keywords or text strings. The Job MIB is trying to have job attributes like IPP has Job attributes. >> There are strange TCs among them, for example the >> JmBooleanTC, which to me does not look like a Boolean >> since it can have 3 values!!?? >> And we have a standard TC for a boolean: TruthValue in RFC1903 The JmBooleanTC does have three values. The third value is 'unknown'. That is used for the case when the agent doean't know whether the value is 'true' or 'false'. >> >> 2.The use of MUST, MAY, SHOULD, SHALL, MUST NOT and such >> seems completely nonsense the me. It looks as if they >> capitalized evry occurence of such words. There are 5 or so MUSTs and a large number of SHALLs. Should we change the 5 MUSTs to SHALL to be consistent? There are a few sentences that have SHALL which are descriptive sentences, rather than describing an action by the agent or the NMS (management application). Those descriptive sentences should have the SHALL removed. However, shouldn't any sentence that has the agent or the NMS (management application) as the subject of the sentence have a SHALL, if that action is required for a conforming agent or management application? >> >> 3.The structure of the MIB is totaly "non-SNMP" like. I suspect that you are referring to the attribute mechanism which like a 'dictionary'. We have found that for Printers and Jobs, that the features that various implementors implement vary so much that we couldn't have groups of objects. Many objects in a group would return 'empty strings', since there was no value to go with them. Most implementations need to be able to pick and choose between the various attributes. Some implement two-sided printing, some implement stapling, some implement job names, some implement document names, some implement multiple documents per job, some count sheets, some count impressions, some can only count octets, etc. etc. >> It is the 2nd wierdest MIB I have ever seen. >> I have difficulty saying go ahead and publish. >> But... it is work of the PWG which is outside of the >> IETF, right? So not sure what we can/should do. >> I would certainly NOT let this thing go on the standards >> track. See the comments from David Perkins of over a year ago (attached) which did not object to the attribute mechanism, though he did suggest that we make the attributes be two tables, instead of one. We kept the table as one, since there are some attributes that have both an integer and a string value. We took account of all his other comments. The area directors rejected putting the Job MIB on the standards track a year ago on the grounds that it was an application, not something that managed the network. There was no concern about the attribute mechanism mentioned then. >> >> 4.Several references may need to be changed/updated. No doubt. This document is over five months old. Should we attempt to determine which ones are out of date? > >My understanding was that one of the O&M ADs was supposed to >contact you about this, to better understand how the problems >might be fixed. This might have been delayed since many of >the IESG folks were at the ISOC conference in Geneva last week. > >Keith > > >Reply-To: >From: "David T. Perkins" >To: , , >Subject: Review of Job Monitoring MIB >Date: Fri, 27 Jun 1997 01:18:07 PDT >X-Msmail-Priority: Normal >X-Mailer: Microsoft Internet Mail 4.70.1155 > >HI > >I finished looking over the document. (I spent about 5 hours) >In general, the objects that are defined in the MIB module are >relatively few in number and easy to understand. However, the >document has some problems and the MIB module has some problems >that can be easily solved without changing the semantics of >the MIB objects or losing any capabilities. > >There is one change that would affect any current implementations >that I strongly suggest that you do. Table jmAttributeTable has >three accessible columnar objects. The first tells you the "type" >(either integer, octet, or both) of the value of the attribute. >The second two columns are the attribute's value. I suggest that >instead of this single table, that you have two tables. Each table >would have a single accessible column. The first table would contain >integer valued attributes, and the second table would contain >octet string valued attributes. > >On the document itself, none of the cross references seemed valid! >In general you have way too much text in the descriptions for the >textual conventions and objects that should be in the text that >comes before the MIB module. > >The MIB and the agent don't "instrument" a managed device. An SNMP >agent provided access to instrumentation. Thus, many times throughout >the document were I saw sentences like the following, it would cause >me to grit my teeth: > An agent is the network entity that accepts SNMP requests from a > monitor and implements the Job Monitoring MIB by instrumenting > a server or a device. >This is not correct! A correction of the above text is the following >text: > An agent is the network entity that accepts SNMP requests from a > monitor (an SNMP management application) and provides access to the > instrumentation for managing jobs modeled by the management objects > defined in the Job Monitoring MIB module. > >The reason why the original text is not correct is that the instrumentation >is independent of the mechanism used to access the management information. >That is, the instrumentation could have a local interface so that a >program could be run on the server or device that displayed management >information on a local console. > >On your configurations of printers-clients-servers, you specify three >and say that configuration 2 is not the design center for the document. >I don't understand. I think that configuration 2 would be the most common >and think that configuration 3 is unworkable. (How would configuration 3 >work if there were a pool of printers?) > >The approach to specifying conformance is quite inappropriate. SMIv2 has >a well defined mechanism which is not being used properly. Yes you have >a module compliance specification, but you also have compliance >specifications all through the MIB module in ASN.1 comments. You need to >remove the ASN.1 comments with compliance specifications. In the text >of the document, you simply specify the compliance specifications by >referencing the one or more module compliance specifications in the >MIB module! >The conformances for management applications is sort of silly. You >basically say that they cannot have bugs and must correctly implement >and use SNMP. This is silly and should be removed. > >The module has a problem with all the objects that have type of OCTET >STRING. >You really need to enforce a code-point mapping. Consider a management >application. What are they to do with the values? Do they try to figure >out the encoding, or ask the user of the application for a hint, or what? > >The text of section 8.1 is invalid. No other definition of MIB objects >can cause the access for MIB objects in the current module to change. > >The text of section 9 is bogus to the max. The "normal SNMP practice" that >you describe does not exist. What you really want to say is something like >the following: > > 9. Values for Objects > SNMP requires that if an object cannot be implemented because its values > cannot be accessed, then a compliant agent must return an SNMP error in > SNMPv1 or an exception value in SNMPv2. This MIB has been designed so >that > all objects can be implemented. In general, values for objects have been > chosen so that a management application will be able to determine if > a useful value is available for an object. The approach is to define > the value 'unknown(2)' for enums, the value '-2' for integers, and the > zero length string for octet strings to mean that a useful value is > not available for an object. > >Section 10 should be called just "Notifications" and not "Notifications >and Traps". The first sentence should be "this MIB module does not specify >any notifications." > >At the beginning of the MIB module, you did a good thing by providing the >RFC editor with instructions for what to do when the document is published. >However, the details were not quite correct. You cannot have the definition >"temp OBJECT IDENTIFIER ::= { experimental 54 }" before the module identity >construct. You should delete the definition "temp OBJECT IDENTIFIER ::= { >experimental 54 }, and specify the value for jobmonMIB as >{ experimental 54 105 }, and fix the editing instructions in the comment >before the module compliance. > >Throughout the MIB module the text references pages and items in the >reference section. This is a really bad thing to do, since these references >will have not meaning after the MIB module is extracted from the document! >Get rid of them. In the description for the module identity, create >short labels for items found in the references section of the document, >and use those labels in text in the MIB module. For example, to reference >RFC 1213, you might add the following in the description: > [MIB-2] - RFC 1213 >And specify "[MIB-2]" in your other descriptions, instead of [5] from your >references section of the document. > >Add the WG email and WEB site in the CONTACT-INFO description text. I'm >sure >that you do not want to be contacted by every university student that >was assigned a project to write a management application that uses the >job monitoring MIB. > >All the ASN.1 comments for each enumerated value should be in the >description >text for the TC. Thus, a TC definition should look something like the >following: > MyTC ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION "bla..bla..bla.. > The values are: > v1(1)...bla-bla-bla > v2(2)...bla-bla-bla > ... > vn(n)...bla-bla-bla" > SYNTAX INTEGER {v1(1), v2(2), ...vn(n)} > >In general, you provide text in the descriptions for the TCs and the values >of the TCs that should go in the text of the document. > >Figure 4 for TC JmJobState is messed up (due to formatting problems?). > >The description for TC jmAttributeTypeTC is quite bogus. It is not longer >needed, if you follow my suggestion above. > >The indexing for tables jmGeneralTable and jmJobTable is illegal. (just >because RMON-2 and a could other MIBs did something like this does not >make it legal.) > >Several of your objects need a units clause, such as >jmGeneralJobPersistence. > >I believe that the "helpful note" in the description for row jmJobIdEntry >will cause more confusion than provide help. > >You have a typo for the RFC number of the printer MIB. It should be >RFC 1759 and not RFC 1579. > >That's it for now. >Regards, >/david t. perkins > > > From hastings at cp10.es.xerox.com Tue Jul 28 02:32:50 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: job mib feedback [more explanation about attributes] In-Reply-To: <199807271855.OAA19942@spot.cs.utk.edu> Message-ID: <3.0.5.32.19980727233250.00bf91c0@garfield> At 11:55 07/27/98 PDT, Keith Moore wrote: snip ... >> 3.The structure of the MIB is totaly "non-SNMP" like. >> It is the 2nd wierdest MIB I have ever seen. >> I have difficulty saying go ahead and publish. >> But... it is work of the PWG which is outside of the >> IETF, right? So not sure what we can/should do. >> I would certainly NOT let this thing go on the standards >> track. This is a more complete explanation of the reason that we advanced the attribute structure in the PWG job monitoring MIB. Its been prototyped for over a year. The reason for the new structure is that we found in doing the Printer MIB (RFC 1759) that printers vary from model to model and vendor to vendor that attempting to combine objects into a group for perpurposes of conformance was too difficult. One implementation would only have one or two items in a group, and so would forced with the decision to implement the whole group, returning empty strings or other(1) enums for most of the objects or omit the group entirely. So we invented the attribute concept which is conceptually like most job submission protocols, such as IPP, DPA, or LPD, in that an implementation of a job need only support the attributes that the device or server contains. Furthermore, each job submission could omit any attributes that were not needed for that job. The idea is that a TC defines the enum values that identify each attribute. That enum is used as a index into the attribute table. Thus an NMS can either access the attribute directly with a Get operation specifying the index enum value for that attribute or can "harvest" a bunch of attributes doing GetNext, skipping over the unimplemented or unsupplied attributes for that job. We also added one final index to allow an attribute to have more than one value (integer or octet string), as in most job submission protocols. So, while the Job MIB doesn't look like other MIBs, its attribute concept reflects the semantics of jobs that have attributes. Also the indexing, Get, and GetNext semantics seems to lend themselves well for representing jobs which vary so much between product implementations and between each job submission with a particular product. Does that make sense? Thanks, Tom From hastings at cp10.es.xerox.com Tue Jul 28 03:38:22 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:15 2009 Subject: JMP> Re: job mib feedback [more explanation about attributes] In-Reply-To: <3.0.5.32.19980727233250.00bf91c0@garfield> References: <199807271855.OAA19942@spot.cs.utk.edu> Message-ID: <3.0.5.32.19980728003822.02072c00@garfield> At 11:55 07/27/98 PDT, Keith Moore wrote: snip ... >> 3.The structure of the MIB is totaly "non-SNMP" like. >> It is the 2nd wierdest MIB I have ever seen. >> I have difficulty saying go ahead and publish. >> But... it is work of the PWG which is outside of the >> IETF, right? So not sure what we can/should do. >> I would certainly NOT let this thing go on the standards >> track. To see the variations of job submission protocols for representing job objects, we mapped the attributes of 10 print job submission protocols to the Job Monitoring MIB. Please refer to draft-ietf-printmib-job-protomap-03.txt. It shows that some job submission protocols have very few attributes and some have a lot of attributes. Many printers have to support more than one job submission protocol. The Job MIB is attempting to allow a printer that supports multiple job submission protocols to support them with a single MIB. Thus the Job MIB allows a management application to query jobs that were submitted using different job submission protocol, but that are all in the same "queue" for the printer, and get their job attributes. Thanks, Tom From rbergma at dpc.com Wed Aug 12 15:51:23 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:15 2009 Subject: JMP> Anyone for an Interoperability Test? Message-ID: There has been some interest in a Job Monitoring MIB interoperability test. Please respond if you have an interest and when will you be ready to test. Ron Bergman Dataproducts Corp. From Angelo.Caruso at usa.xerox.com Thu Aug 13 14:13:09 1998 From: Angelo.Caruso at usa.xerox.com (Caruso, Angelo ) Date: Wed May 6 14:00:16 2009 Subject: JMP> Anyone for an Interoperability Test? Message-ID: <576F850CF0D5D111A38100805FC7FA0E1A84A8@usa0111ms2.eng.mc.xerox.com> Gee, it's awfully quiet out there. Who expressed interest in an interop test? Speaking for the Xerox Channels Group, we do not have anything ready for an interop test in the next couple of months. Thanks, Angelo -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Wednesday, August 12, 1998 3:51 PM To: jmp@pwg.org Subject: JMP> Anyone for an Interoperability Test? There has been some interest in a Job Monitoring MIB interoperability test. Please respond if you have an interest and when will you be ready to test. Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Thu Aug 13 19:56:35 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:16 2009 Subject: JMP> Anyone for an Interoperability Test? Message-ID: <5030100024539168000002L082*@MHS> IBM is definitely interested in a Job MIB interop test. The 2 month time frame is OK with us. We would need some time to determine how to test such a dynamic environment, anyway. One thing I think we might want to do is arrange it as an interoperability demonstration rather than a full compliance test. In this context, we would be willing to supply a version of our NT Port monitor using the Job MIB as a client that would interoperate with anyone's printer. However, we would emphasize, our client would not be considered a compliance test tool. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 08/13/98 05:49:09 PM Please respond to jmp-owner@pwg.org To: jmp@pwg.org, rbergma@dpc.com cc: Subject: RE: JMP> Anyone for an Interoperability Test? Gee, it's awfully quiet out there. Who expressed interest in an interop test? Speaking for the Xerox Channels Group, we do not have anything ready for an interop test in the next couple of months. Thanks, Angelo -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Wednesday, August 12, 1998 3:51 PM To: jmp@pwg.org Subject: JMP> Anyone for an Interoperability Test? There has been some interest in a Job Monitoring MIB interoperability test. Please respond if you have an interest and when will you be ready to test. Ron Bergman Dataproducts Corp. From don at lexmark.com Mon Sep 14 15:26:47 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Mailing Lists Message-ID: <199809141927.AA13984@interlock2.lexmark.com> The mailing lists are back up and running. Just to test everything out, I have sent this mail to ALL the mailing lists. If you get this mail on one list and not on another you think you should be on then I suggest you resubscribe by sending e-mail to: majordomo@pwg.org with the body of the note containing subscribe when is the name of the list you wish to subscribe to. You can include multiple subscriptions in the same note. Thanks for your patience during this transfer. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From jfung at cp10.es.xerox.com Wed Sep 16 12:37:21 1998 From: jfung at cp10.es.xerox.com (Joseph Z. Fung) Date: Wed May 6 14:00:16 2009 Subject: JMP> Job Submission Protocol Mapping Implementation In-Reply-To: Message-ID: <3.0.1.32.19980916093721.0131ca28@goldie> Ron, As the author of the "Job Submission Protocol Mapping" specification, currently at version 10, could you share any known implementations to-date that are based on this recommendation? I am more interested in the mapping for submission protocols of lpr/lpd, PJL, and PostScript. Thank you very much in advance. //Joe Fung Xerox Corp. From rbergma at dpc.com Thu Sep 17 16:19:47 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> MIBs Meeting Schedule Message-ID: I propose that the evening MIBs meetings be either Wednesday or Thursday evening, rather than Tuesday. Most of the people attending this meeting do not attend the P1394 meetings. In many cases such as the Savannah meeting, it is difficult to arrive early enough to be at the start of the meeting. (I will be late to the UPD meeting which replaces the MIBs meeting in Savannah.) Rather than start the meeting later than 7:00, Wednesday would be much more convenient. Anyone object to Wednesday evening in Tucson? Comments? Ron Bergman Dataproducts Corp. From Stuart.Rowley at kyocera.com Thu Sep 17 17:48:49 1998 From: Stuart.Rowley at kyocera.com (Stuart Rowley) Date: Wed May 6 14:00:16 2009 Subject: JMP> Re: PWG> MIBs Meeting Schedule Message-ID: <00063E81.@kyocera.com> Ron, Yes, I'm in favor of MIBs on Wednesday nights. For Savannah I will likely miss the entire UPD meeting because my flight arrives at 6:55 PM although I leave SFO at 6:15 AM! Stuart Rowley Kyocera Technology Development ______________________________ Reply Separator _________________________________ Subject: PWG> MIBs Meeting Schedule Author: INTERNET:rbergma@dpc.com at CSERVE Date: 9/17/98 4:37 PM I propose that the evening MIBs meetings be either Wednesday or Thursday evening, rather than Tuesday. Most of the people attending this meeting do not attend the P1394 meetings. In many cases such as the Savannah meeting, it is difficult to arrive early enough to be at the start of the meeting. (I will be late to the UPD meeting which replaces the MIBs meeting in Savannah.) Rather than start the meeting later than 7:00, Wednesday would be much more convenient. Anyone object to Wednesday evening in Tucson? Comments? Ron Bergman Dataproducts Corp. From don at lexmark.com Fri Sep 18 10:09:36 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> MIBs Meeting Schedule Message-ID: <199809181410.AA15487@interlock2.lexmark.com> The reason we set this up for Tuesday was as Harry suggested -- it would be better to do this on an evening when you were fresh, i.e. not after an IPP meeting. Since most of the attendees do not attend 1394 meetings, most would be "fresh" having it on another day is alright me me, just make sure the meeting coordinator of Tucson (Alan Berkema) knows to ask for the room on Wednesday or Thursday evening rather than Tuesday. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** Ron Bergman on 09/17/98 04:19:47 PM To: pwg%@pwg.org@interlock.lexmark.com, fin%@pwg.org@interlock.lexmark.com, jmp%@pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) bcc: Don Wright/Lex/Lexmark Subject: PWG> MIBs Meeting Schedule I propose that the evening MIBs meetings be either Wednesday or Thursday evening, rather than Tuesday. Most of the people attending this meeting do not attend the P1394 meetings. In many cases such as the Savannah meeting, it is difficult to arrive early enough to be at the start of the meeting. (I will be late to the UPD meeting which replaces the MIBs meeting in Savannah.) Rather than start the meeting later than 7:00, Wednesday would be much more convenient. Anyone object to Wednesday evening in Tucson? Comments? Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Sun Sep 20 17:12:10 1998 From: hastings at cp10.es.xerox.com (Tom Hastings) Date: Wed May 6 14:00:16 2009 Subject: FIN> JMP> PMP> MIBs Meeting Schedule In-Reply-To: Message-ID: <3.0.5.32.19980920141210.00bcc330@garfield> I agree with Ron. Lets move the MIB meeting from Tuesday evening to Wednesday evening for Tucson (and future meetings). Tom At 13:19 09/17/98 PDT, Ron Bergman wrote: >I propose that the evening MIBs meetings be either Wednesday or Thursday >evening, rather than Tuesday. Most of the people attending this meeting >do not attend the P1394 meetings. In many cases such as the Savannah >meeting, it is difficult to arrive early enough to be at the start of the >meeting. (I will be late to the UPD meeting which replaces the MIBs >meeting in Savannah.) > >Rather than start the meeting later than 7:00, Wednesday would be much >more convenient. Anyone object to Wednesday evening in Tucson? > >Comments? > > > Ron Bergman > Dataproducts Corp. > > > > From rbergma at dpc.com Mon Sep 21 16:05:49 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Re: job mib feedback (fwd) Message-ID: As you can see there has been some activity directed towards the Job MIB since the last meeting. I received the following today from Bert Wijnen, who is helping to move the MIB to RFC status. I would like to discuss the following comments in the Savannah meeting on Friday. We need to either revise the document or justify our position. It is our best interests to revise the documents to conform as long as the change does not functionally change the MIB. Any comments or discussion prior to the meeting would be helpful. Ron Bergman Dataproducts Corp. ---------- Forwarded message ---------- Date: Mon, 21 Sep 98 20:25:11 DST From: Bert Wijnen To: rbergma@unspecified-domain, lpyoung@lexmark.com, chrisw@iwl.com Cc: moore@cs.utk.edu, hastings@cp10.es.xerox.com, harryl@us.ibm.com Subject: JMP> Re: job mib feedback (fwd) Ref: Your note of Mon, 21 Sep 1998 07:35:32 -0700 (Pacific Da Subject: Re: JMP> Re: job mib feedback (fwd) OK, if you are going to do another revision, then pls consider these comments. Up to you how much you pick up. >From Perkins: - misuse of the REFERENCE clause for objects to indicate implementation requirements, and - defining objects with read-only maximum access when it appears that at least read-write access is appropriate. There might be (and probably are) more technical problems, but my review time was limited. >From Keith McCloghrie 1. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. 2. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. 3. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. Bert From rbergma at dpc.com Mon Sep 28 16:18:33 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Job MIB Issues for Savannah PWG Meeting Message-ID: The following are issues relating to the Job MIB that should be discussed this Friday in Savannah. My recommended action is included with each item. A. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. From RFC 1902: "The REFERENCE clause, which need not be present contains a textual cross-reference to an object assignment defined in some other information module. This is useful when de-osifying a MIB module produced by some other organization." ACTION: Delete all REFERENCE clauses and move reference information into DESCRIPTION when appropriate. B. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. ACTION: Move all attribute enumeration definitions to a new section outside of the MIB portion. C. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. From RFC 2119: "These words are often capitalized." "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)" ACTION: Review the use of these words and remove or change to lower case any that are not absolutely necessary. D. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. ACTION: Respond to Keith McCloghrie explaining that this is not a standardized display format. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Sep 28 18:48:13 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Job MIB Issues for Savannah PWG Meeting Message-ID: <918C79AB552BD211A2BD00805F15CE8527F0D1@x-crt-es-ms1.cp10.es.xerox.com> I have some comments and questions. Perhaps some of these should be sent to the IESG commenters before the JMP meeting to get their feedback? Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Monday, September 28, 1998 13:19 To: jmp@pwg.org Cc: Tom Hastings Subject: JMP> Job MIB Issues for Savannah PWG Meeting The following are issues relating to the Job MIB that should be discussed this Friday in Savannah. My recommended action is included with each item. A. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. From RFC 1902: "The REFERENCE clause, which need not be present contains a textual cross-reference to an object assignment defined in some other information module. This is useful when de-osifying a MIB module produced by some other organization." ACTION: Delete all REFERENCE clauses and move reference information into DESCRIPTION when appropriate. TH> Ok. B. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. ACTION: Move all attribute enumeration definitions to a new section outside of the MIB portion. TH> The only reason that the definitions were ASN.1 comments, was because TH> an unnamed, but very popular and good, MIB compiler would not accept TH> a DESCRIPTION clause with that number of lines, so we had to make them TH> ASN.1 comments. TH> The question that I have is, if we move all attribute definitions TH> out of the MIB portion altogether, will we make the MIB module TH> almost useless when "the MIB, i.e., section 4, is required to be TH> extracted and used stand-alone" as described in point 1 above?. C. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. From RFC 2119: "These words are often capitalized." "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)" ACTION: Review the use of these words and remove or change to lower case any that are not absolutely necessary. TH> We should change any that are not required for interoperability. TH> However, I think that most of them are required for interoperability. D. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. ACTION: Respond to Keith McCloghrie explaining that this is not a standardized display format. TH> I agree. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Sep 28 18:50:46 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Re: job mib feedback (fwd) Message-ID: <918C79AB552BD211A2BD00805F15CE8527F0D4@x-crt-es-ms1.cp10.es.xerox.com> We may want to reply to David Perkins that we don't think that any of the object should be MAX ACCESS of READ-WRITE. This is only a Monitoring MIB. Should we? Thanks, Tom -----Original Message----- From: Ron Bergman [mailto:rbergma@dpc.com] Sent: Monday, September 21, 1998 13:06 To: jmp@pwg.org Subject: JMP> Re: job mib feedback (fwd) As you can see there has been some activity directed towards the Job MIB since the last meeting. I received the following today from Bert Wijnen, who is helping to move the MIB to RFC status. I would like to discuss the following comments in the Savannah meeting on Friday. We need to either revise the document or justify our position. It is our best interests to revise the documents to conform as long as the change does not functionally change the MIB. Any comments or discussion prior to the meeting would be helpful. Ron Bergman Dataproducts Corp. ---------- Forwarded message ---------- Date: Mon, 21 Sep 98 20:25:11 DST From: Bert Wijnen To: rbergma@unspecified-domain, lpyoung@lexmark.com, chrisw@iwl.com Cc: moore@cs.utk.edu, hastings@cp10.es.xerox.com, harryl@us.ibm.com Subject: JMP> Re: job mib feedback (fwd) Ref: Your note of Mon, 21 Sep 1998 07:35:32 -0700 (Pacific Da Subject: Re: JMP> Re: job mib feedback (fwd) OK, if you are going to do another revision, then pls consider these comments. Up to you how much you pick up. >From Perkins: - misuse of the REFERENCE clause for objects to indicate implementation requirements, and - defining objects with read-only maximum access when it appears that at least read-write access is appropriate. There might be (and probably are) more technical problems, but my review time was limited. >From Keith McCloghrie 1. The following is inappropriate in an IESG standards document: -- jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) -- OCTETS: The calendar date and time of day after which the -- job SHALL become a candidate to be scheduled for -- processing. If the value of this attribute is in the -- future, the server SHALL set the value of the job's -- jmJobState object to pendingHeld and add the -- jobProcessAfterSpecified bit value to the job's -- jmJobStateReasons1 object. When the specified date and -- time arrives, the server SHALL remove the -- jobProcessAfterSpecified bit value from the job's -- jmJobStateReasons1 object and, if no other reasons remain, -- SHALL change the job's jmJobState object to pending. the IETF does not standardize the format in which an application program displays its output. DISPLAY-HINT, which is only a "hint", is the closest we get to that. 2. Defining the meaning of enumerated labels in ASN.1 comments (as is done in the definition of JmAttributeTypeTC) is not conformant to the SMI. 3. Many REFERENCE clauses in this MIB refer other sections of the document. This is not allowed by the SMI, because the MIB, i.e., section 4, is required to be extracted and used stand-alone. I am also very surprised about the VERY superfluous use of capitalized SHALL, MUST, SHOULD, MAY etc. Bert From hastings at cp10.es.xerox.com Tue Oct 6 20:24:11 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> I've posted Job MIB V1.2 with Savannah agreements Message-ID: <918C79AB552BD211A2BD00805F15CE8527F7C4@x-crt-es-ms1.cp10.es.xerox.com> This has the two new attributes agreed to last April: mediumSizeConsumed and mediumTypeConsumed and the IESG comments incorporated. The .txt file compiles. The files are at: ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.pdf I've not sent it as an I-D yet. Lets see if you have any comments. I'll also send out the mirror table ASN.1 separately for discussion in a day or two. Tom Hastings (310) 333-6413 From don at lexmark.com Wed Oct 7 15:37:22 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> I've posted Job MIB V1.2 with Savannah agreements Message-ID: <199810071937.AA18363@interlock2.lexmark.com> .... and the real URL has pwg between pub and jmp..... Don "Hastings, Tom N" on 10/06/98 08:24:11 PM To: jmp%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) bcc: Don Wright/Lex/Lexmark Subject: JMP> I've posted Job MIB V1.2 with Savannah agreements This has the two new attributes agreed to last April: mediumSizeConsumed and mediumTypeConsumed and the IESG comments incorporated. The .txt file compiles. The files are at: ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/jmp/mibs/jmp-mib-rev.pdf I've not sent it as an I-D yet. Lets see if you have any comments. I'll also send out the mirror table ASN.1 separately for discussion in a day or two. Tom Hastings (310) 333-6413 From rbergma at dpc.com Thu Oct 8 16:46:06 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Review of Job Monitoring MIB of October 2, 1998 Message-ID: Tom, Your proposed changes look very good! I did notice that there are four other TCs that reflect the same situation as with JmAttributeTypeTC. They are: JmFinishingTypeTC JmMediumTypeTC JmJobSubmissionTypeTC JmJobStateTC In the case of the first two, the definitions could be added as comments with the enums. For the second two, the specs should also be moved out of the MIB and into the text I will submit a proposal for these changes unless the other JMP participants feel strongly that a change here is not required. Also the bit-mapped TCs are structured very different than what is in the current Printer MIB and the HR MIB. I suggest everyone look at this and indicate if we should revise. JmJobServiceTypesTC JmJobStateReasonsTC JmJobStateReasons2TC JmJobStateReasons3TC JmJobStateReasons4TC I see that you also changed this to v1.2 ( was v1 ). The editorial changes should not affect the revision status, nor should the addition of the 2 new enums. So I prefer that the MIB remain at v1. Ron Bergman Dataproducts Corp. From hastings at cp10.es.xerox.com Mon Oct 12 11:51:10 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <918C79AB552BD211A2BD00805F15CE853A2A3B@x-crt-es-ms1.cp10.es.xerox.com> >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Thursday, October 08, 1998 13:46 >To: Tom Hastings; Harry Lewis >Cc: jmp@pwg.org >Subject: Review of Job Monitoring MIB of October 2, 1998 > > >Tom, > >Your proposed changes look very good! > >I did notice that there are four other TCs that reflect the >same situation >as with JmAttributeTypeTC. They are: > > JmFinishingTypeTC > JmMediumTypeTC > JmJobSubmissionTypeTC > JmJobStateTC > >In the case of the first two, the definitions could be added >as comments >with the enums. For the second two, the specs should also be >moved out of >the MIB and into the text > >I will submit a proposal for these changes unless the other JMP >participants feel strongly that a change here is not required. I don't think we should bother. It wasn't commented on by the IESG. Moving the explanations out of the TC makes them a lot harder to use. The information is spread to two places. For attributes, because there are so many, it makes sense to move them out. I think that they really objected to having -- in the middle of a DESCRIPTION clause (which I removed in doing 1.2. >Also the bit-mapped TCs are structured very different than >what is in the >current Printer MIB and the HR MIB. I suggest everyone look >at this and >indicate if we should revise. > > JmJobServiceTypesTC > JmJobStateReasonsTC > JmJobStateReasons2TC > JmJobStateReasons3TC > JmJobStateReasons4TC Since the IESG folks didn't comment on them, I think they are fine having the bit assignments and the description of each bit as part of the DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness as hex in the description, then as the decimal equivalent. > >I see that you also changed this to v1.2 ( was v1 ). The editorial >changes should not affect the revision status, nor should the >addition of >the 2 new enums. So I prefer that the MIB remain at v1. Yikes! There would be a terrible confusion problem if we use the same version number for two different versions of the MIB. The minor version number changes shows that some attributes have been added and/ or clarifications. If we don't have a different version number, how can you tell which MIB you have? (Of course, if the TCs were a separate file, then the MIB part could have kept the same version number. But suppose there had been some clarification text added to even the MIB part, then you wind up incrementing the MIB module version number anyway. > > > Ron Bergman > Dataproducts Corp. > > From rbergma at dpc.com Tue Oct 13 10:48:50 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 In-Reply-To: <918C79AB552BD211A2BD00805F15CE853A2A3B@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, Since there have been no comments from others regarding the changes to the TCs, I assume no one else cares. I have this feeling that this will be another issue with the IETF, so I believe it is best if we beat them to the draw. So, unless others support my position, keep it as is. Concerning the version number change, your reply indicates that new attributes and enums cannot be added unless the version number is changed. This is clearly not true. So what other than the editorial changes and the addition of the two attributes makes this version 1.2? Ron On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Thursday, October 08, 1998 13:46 > >To: Tom Hastings; Harry Lewis > >Cc: jmp@pwg.org > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > >Tom, > > > >Your proposed changes look very good! > > > >I did notice that there are four other TCs that reflect the > >same situation > >as with JmAttributeTypeTC. They are: > > > > JmFinishingTypeTC > > JmMediumTypeTC > > JmJobSubmissionTypeTC > > JmJobStateTC > > > >In the case of the first two, the definitions could be added > >as comments > >with the enums. For the second two, the specs should also be > >moved out of > >the MIB and into the text > > > >I will submit a proposal for these changes unless the other JMP > >participants feel strongly that a change here is not required. > > I don't think we should bother. It wasn't commented on by the IESG. Moving > the explanations out of the TC makes them a lot harder to use. The > information is spread to two places. For attributes, because there are so > many, it makes sense to move them out. > > I think that they really objected to having -- in the middle of a > DESCRIPTION clause (which I removed in doing 1.2. > > >Also the bit-mapped TCs are structured very different than > >what is in the > >current Printer MIB and the HR MIB. I suggest everyone look > >at this and > >indicate if we should revise. > > > > JmJobServiceTypesTC > > JmJobStateReasonsTC > > JmJobStateReasons2TC > > JmJobStateReasons3TC > > JmJobStateReasons4TC > > Since the IESG folks didn't comment on them, I think they are fine having > the bit assignments and the description of each bit as part of the > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > as hex in the description, then as the decimal equivalent. > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > >changes should not affect the revision status, nor should the > >addition of > >the 2 new enums. So I prefer that the MIB remain at v1. > > Yikes! There would be a terrible confusion problem if we use the same > version number for two different versions of the MIB. The minor version > number changes shows that some attributes have been added and/ or > clarifications. > > If we don't have a different version number, how can you tell which MIB you > have? (Of course, if the TCs were a separate file, then the MIB part could > have kept the same version number. But suppose there had been some > clarification text added to even the MIB part, then you wind up incrementing > the MIB module version number anyway. > > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > From harryl at us.ibm.com Tue Oct 13 12:31:16 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:16 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <5030100027086306000002L062*@MHS> You were just recommending moving TC's to a consolidated place in the document... right? I didn't see any problem with doing that. Harry Lewis - IBM Printing Systems jmp-owner@pwg.org on 10/13/98 09:07:33 AM Please respond to jmp-owner@pwg.org To: hastings@cp10.es.xerox.com cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Tom, Since there have been no comments from others regarding the changes to the TCs, I assume no one else cares. I have this feeling that this will be another issue with the IETF, so I believe it is best if we beat them to the draw. So, unless others support my position, keep it as is. Concerning the version number change, your reply indicates that new attributes and enums cannot be added unless the version number is changed. This is clearly not true. So what other than the editorial changes and the addition of the two attributes makes this version 1.2? Ron On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Thursday, October 08, 1998 13:46 > >To: Tom Hastings; Harry Lewis > >Cc: jmp@pwg.org > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > >Tom, > > > >Your proposed changes look very good! > > > >I did notice that there are four other TCs that reflect the > >same situation > >as with JmAttributeTypeTC. They are: > > > > JmFinishingTypeTC > > JmMediumTypeTC > > JmJobSubmissionTypeTC > > JmJobStateTC > > > >In the case of the first two, the definitions could be added > >as comments > >with the enums. For the second two, the specs should also be > >moved out of > >the MIB and into the text > > > >I will submit a proposal for these changes unless the other JMP > >participants feel strongly that a change here is not required. > > I don't think we should bother. It wasn't commented on by the IESG. Moving > the explanations out of the TC makes them a lot harder to use. The > information is spread to two places. For attributes, because there are so > many, it makes sense to move them out. > > I think that they really objected to having -- in the middle of a > DESCRIPTION clause (which I removed in doing 1.2. > > >Also the bit-mapped TCs are structured very different than > >what is in the > >current Printer MIB and the HR MIB. I suggest everyone look > >at this and > >indicate if we should revise. > > > > JmJobServiceTypesTC > > JmJobStateReasonsTC > > JmJobStateReasons2TC > > JmJobStateReasons3TC > > JmJobStateReasons4TC > > Since the IESG folks didn't comment on them, I think they are fine having > the bit assignments and the description of each bit as part of the > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > as hex in the description, then as the decimal equivalent. > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > >changes should not affect the revision status, nor should the > >addition of > >the 2 new enums. So I prefer that the MIB remain at v1. > > Yikes! There would be a terrible confusion problem if we use the same > version number for two different versions of the MIB. The minor version > number changes shows that some attributes have been added and/ or > clarifications. > > If we don't have a different version number, how can you tell which MIB you > have? (Of course, if the TCs were a separate file, then the MIB part could > have kept the same version number. But suppose there had been some > clarification text added to even the MIB part, then you wind up incrementing > the MIB module version number anyway. > > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > From rbergma at dpc.com Tue Oct 13 16:47:11 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 In-Reply-To: <5030100027086306000002L062*@MHS> Message-ID: Harry, What I see in the MIB is four other TCs that, like JmAttributeTypeTC, contain very long, detailed specifications of each enumeration in the TC definition. The specification details should be removed from the MIB section. I don't want this to come back from the ADs as aonther fix. If it easy to fix, and I don't see why not, I prefer to do it now and be done with it. Does this make the MIB harder to use? Maybe, maybe not. With all the cross references we have, I don'e see how it could be that much more difficult. Any opinions? Ron Bergman Dataproducts Corp. On Tue, 13 Oct 1998, Harry Lewis wrote: > You were just recommending moving TC's to a consolidated place in the > document... right? I didn't see any problem with doing that. > > Harry Lewis - IBM Printing Systems > > > > jmp-owner@pwg.org on 10/13/98 09:07:33 AM > Please respond to jmp-owner@pwg.org > To: hastings@cp10.es.xerox.com > cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com > Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > > Tom, > > Since there have been no comments from others regarding the changes to the > TCs, I assume no one else cares. I have this feeling that this will be > another issue with the IETF, so I believe it is best if we beat them to > the draw. So, unless others support my position, keep it as is. > > Concerning the version number change, your reply indicates that new > attributes and enums cannot be added unless the version number is changed. > This is clearly not true. So what other than the editorial changes and > the addition of the two attributes makes this version 1.2? > > > Ron > > > On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > > > > > >-----Original Message----- > > >From: Ron Bergman [mailto:rbergma@dpc.com] > > >Sent: Thursday, October 08, 1998 13:46 > > >To: Tom Hastings; Harry Lewis > > >Cc: jmp@pwg.org > > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > > > > >Tom, > > > > > >Your proposed changes look very good! > > > > > >I did notice that there are four other TCs that reflect the > > >same situation > > >as with JmAttributeTypeTC. They are: > > > > > > JmFinishingTypeTC > > > JmMediumTypeTC > > > JmJobSubmissionTypeTC > > > JmJobStateTC > > > > > >In the case of the first two, the definitions could be added > > >as comments > > >with the enums. For the second two, the specs should also be > > >moved out of > > >the MIB and into the text > > > > > >I will submit a proposal for these changes unless the other JMP > > >participants feel strongly that a change here is not required. > > > > I don't think we should bother. It wasn't commented on by the IESG. Moving > > the explanations out of the TC makes them a lot harder to use. The > > information is spread to two places. For attributes, because there are so > > many, it makes sense to move them out. > > > > I think that they really objected to having -- in the middle of a > > DESCRIPTION clause (which I removed in doing 1.2. > > > > >Also the bit-mapped TCs are structured very different than > > >what is in the > > >current Printer MIB and the HR MIB. I suggest everyone look > > >at this and > > >indicate if we should revise. > > > > > > JmJobServiceTypesTC > > > JmJobStateReasonsTC > > > JmJobStateReasons2TC > > > JmJobStateReasons3TC > > > JmJobStateReasons4TC > > > > Since the IESG folks didn't comment on them, I think they are fine having > > the bit assignments and the description of each bit as part of the > > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > > as hex in the description, then as the decimal equivalent. > > > > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > > >changes should not affect the revision status, nor should the > > >addition of > > >the 2 new enums. So I prefer that the MIB remain at v1. > > > > Yikes! There would be a terrible confusion problem if we use the same > > version number for two different versions of the MIB. The minor version > > number changes shows that some attributes have been added and/ or > > clarifications. > > > > If we don't have a different version number, how can you tell which MIB you > > have? (Of course, if the TCs were a separate file, then the MIB part could > > have kept the same version number. But suppose there had been some > > clarification text added to even the MIB part, then you wind up incrementing > > the MIB module version number anyway. > > > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > > > > > > > From harryl at us.ibm.com Tue Oct 13 17:47:11 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:16 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <5030100027103065000002L052*@MHS> I agree with Ron. My main concern is that we not disturb the actual operation of the MIB... this appears to be strictly a documentation issue. Since the IETF mentioned one such example, if we have found 4 similar I think it best to respond. Harry Lewis - IBM Printing Systems rbergma@dpc.com on 10/13/98 03:02:46 PM Please respond to rbergma@dpc.com To: Harry Lewis/Boulder/IBM@ibmus cc: hastings@cp10.es.xerox.com, jmp@pwg.org Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Harry, What I see in the MIB is four other TCs that, like JmAttributeTypeTC, contain very long, detailed specifications of each enumeration in the TC definition. The specification details should be removed from the MIB section. I don't want this to come back from the ADs as aonther fix. If it easy to fix, and I don't see why not, I prefer to do it now and be done with it. Does this make the MIB harder to use? Maybe, maybe not. With all the cross references we have, I don'e see how it could be that much more difficult. Any opinions? Ron Bergman Dataproducts Corp. On Tue, 13 Oct 1998, Harry Lewis wrote: > You were just recommending moving TC's to a consolidated place in the > document... right? I didn't see any problem with doing that. > > Harry Lewis - IBM Printing Systems > > > > jmp-owner@pwg.org on 10/13/98 09:07:33 AM > Please respond to jmp-owner@pwg.org > To: hastings@cp10.es.xerox.com > cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com > Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > > Tom, > > Since there have been no comments from others regarding the changes to the > TCs, I assume no one else cares. I have this feeling that this will be > another issue with the IETF, so I believe it is best if we beat them to > the draw. So, unless others support my position, keep it as is. > > Concerning the version number change, your reply indicates that new > attributes and enums cannot be added unless the version number is changed. > This is clearly not true. So what other than the editorial changes and > the addition of the two attributes makes this version 1.2? > > > Ron > > > On Mon, 12 Oct 1998, Hastings, Tom N wrote: > > > > > > > >-----Original Message----- > > >From: Ron Bergman [mailto:rbergma@dpc.com] > > >Sent: Thursday, October 08, 1998 13:46 > > >To: Tom Hastings; Harry Lewis > > >Cc: jmp@pwg.org > > >Subject: Review of Job Monitoring MIB of October 2, 1998 > > > > > > > > >Tom, > > > > > >Your proposed changes look very good! > > > > > >I did notice that there are four other TCs that reflect the > > >same situation > > >as with JmAttributeTypeTC. They are: > > > > > > JmFinishingTypeTC > > > JmMediumTypeTC > > > JmJobSubmissionTypeTC > > > JmJobStateTC > > > > > >In the case of the first two, the definitions could be added > > >as comments > > >with the enums. For the second two, the specs should also be > > >moved out of > > >the MIB and into the text > > > > > >I will submit a proposal for these changes unless the other JMP > > >participants feel strongly that a change here is not required. > > > > I don't think we should bother. It wasn't commented on by the IESG. Moving > > the explanations out of the TC makes them a lot harder to use. The > > information is spread to two places. For attributes, because there are so > > many, it makes sense to move them out. > > > > I think that they really objected to having -- in the middle of a > > DESCRIPTION clause (which I removed in doing 1.2. > > > > >Also the bit-mapped TCs are structured very different than > > >what is in the > > >current Printer MIB and the HR MIB. I suggest everyone look > > >at this and > > >indicate if we should revise. > > > > > > JmJobServiceTypesTC > > > JmJobStateReasonsTC > > > JmJobStateReasons2TC > > > JmJobStateReasons3TC > > > JmJobStateReasons4TC > > > > Since the IESG folks didn't comment on them, I think they are fine having > > the bit assignments and the description of each bit as part of the > > DESCRIPTION clause. Also I think it is a lot clearer to show the bit-ness > > as hex in the description, then as the decimal equivalent. > > > > > > > >I see that you also changed this to v1.2 ( was v1 ). The editorial > > >changes should not affect the revision status, nor should the > > >addition of > > >the 2 new enums. So I prefer that the MIB remain at v1. > > > > Yikes! There would be a terrible confusion problem if we use the same > > version number for two different versions of the MIB. The minor version > > number changes shows that some attributes have been added and/ or > > clarifications. > > > > If we don't have a different version number, how can you tell which MIB you > > have? (Of course, if the TCs were a separate file, then the MIB part could > > have kept the same version number. But suppose there had been some > > clarification text added to even the MIB part, then you wind up incrementing > > the MIB module version number anyway. > > > > > > > > > > > Ron Bergman > > > Dataproducts Corp. > > > > > > > > > > > > > From rbergma at dpc.com Tue Oct 13 21:21:35 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> MIBs Meeting Minutes from Savannah Message-ID: The meeting minutes are posted as follows. These are from Harry Lewis' and my notes. I created one set of minutes for the entire day and posted to both the JMP and FIN directories. ftp://ftp.pwg.org/pub/pug/jmp/minutes/jmp-1098.doc (.txt) ftp://ftp.pwg.org/pub/pug/fin/minutes/fin-1098.doc (.txt) The text version is attached: Ron Bergman Dataproducts Corp. -------------- next part -------------- PWG MIBs MEETING MINUTES Savannah, Georgia October 2, 1998 Job MIB Although the Job MIB has been a completed PWG standard for several months, there have been some recent comments from the IETF in response to our efforts to have them published as RFC standards. 1. The MIB is entirely R/O. (This is by design). ACTION: Respond to David Perkins explaining that this is only a monitoring MIB. For security reasons, the Working Group agreed that the MIB would not contain any read- write objects. 2. We have inadvertently misused the REFERENCE clause. ACTION: Delete all REFERENCE clauses and move reference information into the DESCRIPTION clause when appropriate. 3. We need to move the definition of enumerated labels to a new section outside of the MIB portion. 4. We MIGHT have used too many SHOULDs and SHALLs (surprised? ;-). ACTION: Review the use of these words and remove or change to lower case any that are not absolutely necessary. 5. JobProcessAfterDateAndTime - there was a comment about improper or nonstandard use, but we do not understand the comment. We need to clarify with the reviewer. ACTION: Respond to Keith McCloghrie explaining that this is not a standardized display format. Tom Hastings comments: 1. A new draft was presented with changes in response to items 2, 3, and 4. 2. Two new attributes added - mediumTypeConsumed and SizeConsumed. Both attributes were previously approved as additions to the MIB. 3. Tom will remove attributes from the table of contents just for brevity. New Issue: Tom Hastings presented a problem discovered by Xerox in using the GetBulk operation with the Attribute table. The present table configuration allows GetBulk to work to obtain all the attributes for a given job or a number of jobs. Tom has proposed a mirror table that inverts the order of the indices so that a GetBulk can obtain an attribute for all jobs. This addition would result in enhanced performance on the client side. Tom will draft the required text and post to the mail list. Today - the Attribute Table is indexed by: - Job index - Attribute type index - Attribute instance The proposed Mirror Table would be indexed by: - Attribute instance - Attribute type index - Job index Job MIB interoperability testing may be possibly within appx. 6 months. Finisher MIB: MIB Changes: 1. Moved the MODULE-IDENTITY to { experimental 64 } Accepted 2. Added the following enums to FinStitchingTypeTC: Accepted stapleDualTop(10), stapleDualBottom(11), stapleDualLeft(12), stapleDualRight(13) 3. Added a new attribute and textual convention: Accepted but change to a type 2 enum and change bottomUp(5) to bottomUp(4). stitchingDirection(31), StitchingDirTypeTC INTEGER: Defines the orientation of the stitching process. StitchingDirTypeTC ::= TEXTUAL-CONVENTION -- This is a type 1 enumeration. STATUS current DESCRIPTION "Defines the direction, relative to the top sheet in the output subunit, that the stitching operation was performed. For a topDown(3) process, the staple will be clinched on the bottom of the stack. This parameter can be used to determine what order the pages of a booklet are to be printed such that the staple clinch will be on the inside of the resulting booklet." SYNTAX INTEGER { unknown(2), topDown(3), bottomUp(5) } 4. Removed the following note from section 6.1: Rejected, new enum is changed to type 2. "There are no type 1 enums in the current draft." 5. As a result of the discussions concerning the Job MIB it was also discussed and agreed to move the specification of the attributes used by FinAttributeTypeTC out from the MIB body and into the text. New Issues from Sharp: 1. Several index objects allow a value of 0. The minimum value should be 1. The following index objects will be changed to correct this problem. finDeviceIndex finSupplyIndex finSupplyMediaInputIndex finDeviceAttributeInstanceIndex 2. There is no enumeration in prtMarkerSupplyUnitTC that is appropriate to staples. It was agreed that an enum, such as "units" or "each" should be added to the TC in the Printer MIB. Common Finisher Interface Discussion: Kevin Palmer (Duplo) had agreed to generate a proposal for the Finisher Device Command Set and the Finisher features, functions, characteristics, and status. Kevin was unable to attend the meeting, but he did submit a list of items that pertain to the above subjects. After a brief review, the group decided that there was not sufficient information to generate further discussion. No additional work on this topic will occur until Kevin's complete proposal is received. Harry Lewis - IBM Printing Systems Ron Bergman - Dataproducts Corp. From harryl at us.ibm.com Wed Oct 14 10:25:50 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:16 2009 Subject: JMP> Minutes PDF Message-ID: <5030100027135838000002L082*@MHS> Ron wrote >The meeting minutes are posted as follows. These are from Harry Lewis' >and my notes. I created one set of minutes for the entire day and posted >to both the JMP and FIN directories. > > ftp://ftp.pwg.org/pub/pug/jmp/minutes/jmp-1098.doc (.txt) > ftp://ftp.pwg.org/pub/pug/fin/minutes/fin-1098.doc (.txt) I posted PDF of same. Harry Lewis - IBM Printing Systems From hastings at cp10.es.xerox.com Wed Oct 21 11:54:50 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 Message-ID: <918C79AB552BD211A2BD00805F15CE853A3486@x-crt-es-ms1.cp10.es.xerox.com> Ok. I'll make the edits. Tom >-----Original Message----- >From: Harry Lewis [mailto:harryl@us.ibm.com] >Sent: Tuesday, October 13, 1998 14:47 >To: rbergma@dpc.com >Cc: jmp@pwg.org; hastings@cp10.es.xerox.com >Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > >I agree with Ron. My main concern is that we not disturb the >actual operation >of the MIB... this appears to be strictly a documentation >issue. Since the IETF >mentioned one such example, if we have found 4 similar I think >it best to >respond. > >Harry Lewis - IBM Printing Systems > > > >rbergma@dpc.com on 10/13/98 03:02:46 PM >Please respond to rbergma@dpc.com >To: Harry Lewis/Boulder/IBM@ibmus >cc: hastings@cp10.es.xerox.com, jmp@pwg.org >Subject: Re: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 > > >Harry, > >What I see in the MIB is four other TCs that, like JmAttributeTypeTC, >contain very long, detailed specifications of each enumeration >in the TC >definition. The specification details should be removed from the MIB >section. I don't want this to come back from the ADs as aonther fix. >If it easy to fix, and I don't see why not, I prefer to do it >now and be >done with it. > >Does this make the MIB harder to use? Maybe, maybe not. With all the >cross references we have, I don'e see how it could be that much more >difficult. > >Any opinions? > > Ron Bergman > Dataproducts Corp. > > >On Tue, 13 Oct 1998, Harry Lewis wrote: > >> You were just recommending moving TC's to a consolidated place in the >> document... right? I didn't see any problem with doing that. >> >> Harry Lewis - IBM Printing Systems >> >> >> >> jmp-owner@pwg.org on 10/13/98 09:07:33 AM >> Please respond to jmp-owner@pwg.org >> To: hastings@cp10.es.xerox.com >> cc: jmp@pwg.org, Harry Lewis/Boulder/IBM@ibmus, rbergma@dpc.com >> Subject: JMP> RE: Review of Job Monitoring MIB of October 2, 1998 >> >> >> Tom, >> >> Since there have been no comments from others regarding the >changes to the >> TCs, I assume no one else cares. I have this feeling that >this will be >> another issue with the IETF, so I believe it is best if we >beat them to >> the draw. So, unless others support my position, keep it as is. >> >> Concerning the version number change, your reply indicates that new >> attributes and enums cannot be added unless the version >number is changed. >> This is clearly not true. So what other than the editorial >changes and >> the addition of the two attributes makes this version 1.2? >> >> >> Ron >> >> >> On Mon, 12 Oct 1998, Hastings, Tom N wrote: >> >> > >> > >> > >-----Original Message----- >> > >From: Ron Bergman [mailto:rbergma@dpc.com] >> > >Sent: Thursday, October 08, 1998 13:46 >> > >To: Tom Hastings; Harry Lewis >> > >Cc: jmp@pwg.org >> > >Subject: Review of Job Monitoring MIB of October 2, 1998 >> > > >> > > >> > >Tom, >> > > >> > >Your proposed changes look very good! >> > > >> > >I did notice that there are four other TCs that reflect the >> > >same situation >> > >as with JmAttributeTypeTC. They are: >> > > >> > > JmFinishingTypeTC >> > > JmMediumTypeTC >> > > JmJobSubmissionTypeTC >> > > JmJobStateTC >> > > >> > >In the case of the first two, the definitions could be added >> > >as comments >> > >with the enums. For the second two, the specs should also be >> > >moved out of >> > >the MIB and into the text >> > > >> > >I will submit a proposal for these changes unless the other JMP >> > >participants feel strongly that a change here is not required. >> > >> > I don't think we should bother. It wasn't commented on by >the IESG. Moving >> > the explanations out of the TC makes them a lot harder to use. The >> > information is spread to two places. For attributes, >because there are so >> > many, it makes sense to move them out. >> > >> > I think that they really objected to having -- in the middle of a >> > DESCRIPTION clause (which I removed in doing 1.2. >> > >> > >Also the bit-mapped TCs are structured very different than >> > >what is in the >> > >current Printer MIB and the HR MIB. I suggest everyone look >> > >at this and >> > >indicate if we should revise. >> > > >> > > JmJobServiceTypesTC >> > > JmJobStateReasonsTC >> > > JmJobStateReasons2TC >> > > JmJobStateReasons3TC >> > > JmJobStateReasons4TC >> > >> > Since the IESG folks didn't comment on them, I think they >are fine having >> > the bit assignments and the description of each bit as part of the >> > DESCRIPTION clause. Also I think it is a lot clearer to >show the bit-ness >> > as hex in the description, then as the decimal equivalent. >> > >> > > >> > >I see that you also changed this to v1.2 ( was v1 ). The >editorial >> > >changes should not affect the revision status, nor should the >> > >addition of >> > >the 2 new enums. So I prefer that the MIB remain at v1. >> > >> > Yikes! There would be a terrible confusion problem if we >use the same >> > version number for two different versions of the MIB. The >minor version >> > number changes shows that some attributes have been added and/ or >> > clarifications. >> > >> > If we don't have a different version number, how can you >tell which MIB you >> > have? (Of course, if the TCs were a separate file, then >the MIB part could >> > have kept the same version number. But suppose there had been some >> > clarification text added to even the MIB part, then you >wind up incrementing >> > the MIB module version number anyway. >> > >> > > >> > > >> > > Ron Bergman >> > > Dataproducts Corp. >> > > >> > > >> > >> >> >> >> >> > > > > > From hastings at cp10.es.xerox.com Wed Oct 21 11:56:00 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute table Message-ID: <918C79AB552BD211A2BD00805F15CE853A3487@x-crt-es-ms1.cp10.es.xerox.com> This mail message contains the complete ASN.1 for the proposal for an OPTIONAL mirror table to be considered for addition to the PWG Job Monitoring MIB. It was agreed at the Savannah JMP meeting that I should forward such a proposal to the jmp mailing list. As also agreed at the Savannah JMP meeting, the implementers from Xerox (and others) will discuss on the jmp mailing list the benefits of this new table for improving the performance of applications that monitoring jobs. The IBM implementers (and others) will discuss whether there are other ways to improve the performance, base on their experience with implementation. NOTE: David Perkin's book on SNMP contains discussion of just such a mirror table in order to give different access methods to the same data. As agreed in Savannah, there are three possible outcomes of the jmp e-mail discussions: 1. The mirror table is not considered worth adding even as an OPTIONAL table, since there are other techniques for getting good performance that do not require any changes to the MIB. 2. The mirror table helps performance sufficiently for some applications, that it should be added as an OPTIONAL table (as proposed in this mail message). 3. The mirror table helps performance sufficiently for most applications, and is not a burden to implementation (since only the pointers, not the actual data occurs twice), that it should be made a MANDATORY table. Hopefully the discussions on the mailing list will be sufficiently conclusive that we can finalized on one of the above three courses of action at the upcoming JMP meeting, Tuesday morning, November 10. Discussion ---------------- The 'jmMirrorAttrTable' is a proposed addition to the PWG Job Mon MIB. It supports efficient access to selected job attributes (e.g., reading 'processingMessage' and 'jobStateReasons[2-4]' for all jobs in a job set) via SNMPv1 GetNext or SNMPv2 GetBulk. We have included updates for the MODULE-COMPLIANCE and OBJECT-GROUP macros too. - Ira McDonald SS&A Globalisation Consulting Architect, XCMI Editor 906-494-2434 (work) 906-494-2697 (home) - Tom Hastings PWG Job Monitoring MIB editor (310)333-6413 (work) ------------------------------------------------------------------------ -- The Mirror Attribute Group (OPTIONAL) -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. -- -- Implementation of the objects in this group is OPTIONAL. -- See Section 3.1 entitled 'Conformance Considerations'. -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. -- An agent which implements the jmMirrorAttrTable SHALL create a -- row in the jmMirrorAttrTable when each corresponding row is -- created in the jmAttributeTable. jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } jmMirrorAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmMirrorAttrTable is an OPTIONAL table which contains all of the same attributes for each job that are contained in the jmAttributeTable. Each entry in jmMirrorAttrTable corresponds one-to-one to an entry in jmAttributeTable. See the analogous jmAttributeTable for further details. The jmMirrorAttrTable supports efficient access to all of the attributes that an implementation supports, sorted by attribute type (traditional SNMP MIB access), rather than being sorted by job set and job index (modern object-oriented access) as in the analogous jmAttributeTable. An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." ::= { jmMirror 1 } jmMirrorAttrEntry OBJECT-TYPE SYNTAX JmMirrorAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attributes that represent information about each job and documents or resources required and/or consumed. Each entry in jmMirrorAttrTable corresponds one-to-one to an entry in jmAttributeTable. See the analogous jmAttributeEntry for further details. Each entry in jmMirrorAttrTable is a per-attribute entry with a primary index for each type of attribute (jmMirrorAttrTypeIndex) that a job can have and secondary indices which specify job set (jmJobSetIndex), job instance (jmJobIndex), and attribute instance (jmMirrorAttrInstanceIndex). An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, jmMirrorAttrInstanceIndex } ::= { jmMirrorAttrTable 1 } JmMirrorAttrEntry ::= SEQUENCE { jmMirrorAttrTypeIndex JmAttributeTypeTC, jmMirrorAttrInstanceIndex Integer32 (1..32767), jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) } jmMirrorAttrTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. See jmAttributeTypeIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 1 } jmMirrorAttrInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of attribute that this row entry represents. See jmAttributeInstanceIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 2 } jmMirrorAttrValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. See jmAttributeValueAsInteger in jmAttributeTable for complete description." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmMirrorAttrEntry 3 } jmMirrorAttrValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. See jmAttributeValueAsOctets in jmAttributeTable for complete description." DEFVAL { ''H } -- empty string ::= { jmMirrorAttrEntry 4 } ------------------------------------------------------------------------ [for placement in 'jmMIBCompliance' before the first OBJECT clause] GROUP jmMirrorAttrGroup DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable." ------------------------------------------------------------------------ [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] jmMirrorAttrGroup OBJECT-GROUP OBJECTS { jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } STATUS current DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create a row in the jmMirrorAttrTable when each corresponding row is created in the jmAttributeTable. An agent SHALL maintain each row in the jmMirrorAttrTable for the same time as the corresponding row in the jmAttributeTable." ::= { jmMIBGroups 5 } ------------------------------------------------------------------------ Tom Hastings (310) 333-6413 From rbergma at dpc.com Mon Nov 2 12:05:19 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute table In-Reply-To: <918C79AB552BD211A2BD00805F15CE853A3487@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, I support your proposal to add the optional mirror attribute table to the Job MIB. However, I would like to suggest the following text in place of your proposed text. My changes eliminate much of the very repetitive text that was included in your original draft. Also, you state that section 3.3 contains a description of jmMirrorAttrTable, but you did not provide any changes to this section with this description. (My revised text still contains this reference.) Ron Bergman Dataproducts Corp. ------------------------------------------------------------------------ -- The Mirror Attribute Group (OPTIONAL) -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. -- -- Implementation of the objects in this group is OPTIONAL. -- See Section 3.1 entitled 'Conformance Considerations'. -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. -- -- The jmMirrorAttrTable provides efficient access to all of the -- attributes that an implementation supports, sorted by attribute -- type (traditional SNMP MIB access), rather than being sorted by -- job set and job index (modern object-oriented access) as in the -- analogous jmAttributeTable. jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } jmMirrorAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmMirrorAttrTable is an OPTIONAL table which provides identical attributes to the jmAttributeTable but with a different index structure. See jmAttributeTable for further details. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." ::= { jmMirror 1 } jmMirrorAttrEntry OBJECT-TYPE SYNTAX JmMirrorAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attributes that represent information about each job and documents or resources required and/or consumed. Each entry in jmMirrorAttrTable is a per-attribute entry with a primary index for each type of attribute (jmMirrorAttrTypeIndex) that a job can have and secondary indices which specify job set (jmJobSetIndex), job instance (jmJobIndex), and attribute instance (jmMirrorAttrInstanceIndex). An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, jmMirrorAttrInstanceIndex } ::= { jmMirrorAttrTable 1 } JmMirrorAttrEntry ::= SEQUENCE { jmMirrorAttrTypeIndex JmAttributeTypeTC, jmMirrorAttrInstanceIndex Integer32 (1..32767), jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) } jmMirrorAttrTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. See jmAttributeTypeIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 1 } jmMirrorAttrInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of attribute that this row entry represents. See jmAttributeInstanceIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 2 } jmMirrorAttrValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. See jmAttributeValueAsInteger in jmAttributeTable for complete description." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmMirrorAttrEntry 3 } jmMirrorAttrValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. See jmAttributeValueAsOctets in jmAttributeTable for complete description." DEFVAL { ''H } -- empty string ::= { jmMirrorAttrEntry 4 } ------------------------------------------------------------------------ [for placement in 'jmMIBCompliance' before the first OBJECT clause] GROUP jmMirrorAttrGroup DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ------------------------------------------------------------------------ [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] jmMirrorAttrGroup OBJECT-GROUP OBJECTS { jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } STATUS current DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ::= { jmMIBGroups 5 } ------------------------------------------------------------------------ From harryl at us.ibm.com Mon Nov 2 14:18:30 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribu Message-ID: <5030100027990620000002L002*@MHS> I agree with the addition of an OPTIONAL mirror attribute table and accept Ron's modifications. I'd like to propose one MINOR change, myself... Rather than -- The jmMirrorAttrTable provides efficient access to all of the -- attributes that an implementation supports, sorted by attribute -- type (traditional SNMP MIB access), rather than being sorted by -- job set and job index (modern object-oriented access) as in the -- analogous jmAttributeTable. I request deletion of the word "efficient" in the above. I think, when we developed the tables we have, we did so because we felt it was efficient. I think both methods are efficient based on different perspectives and, therefor, there is no need to embellish the paragraph. Harry Lewis - IBM Printing Systems harryl@us.ibm.com jmp-owner@pwg.org on 11/01/98 10:26:53 PM Please respond to jmp-owner@pwg.org To: hastings@cp10.es.xerox.com cc: jmp@pwg.org Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribu Tom, I support your proposal to add the optional mirror attribute table to the Job MIB. However, I would like to suggest the following text in place of your proposed text. My changes eliminate much of the very repetitive text that was included in your original draft. Also, you state that section 3.3 contains a description of jmMirrorAttrTable, but you did not provide any changes to this section with this description. (My revised text still contains this reference.) Ron Bergman Dataproducts Corp. ------------------------------------------------------------------------ -- The Mirror Attribute Group (OPTIONAL) -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. -- -- Implementation of the objects in this group is OPTIONAL. -- See Section 3.1 entitled 'Conformance Considerations'. -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. -- -- The jmMirrorAttrTable provides efficient access to all of the -- attributes that an implementation supports, sorted by attribute -- type (traditional SNMP MIB access), rather than being sorted by -- job set and job index (modern object-oriented access) as in the -- analogous jmAttributeTable. jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } jmMirrorAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmMirrorAttrTable is an OPTIONAL table which provides identical attributes to the jmAttributeTable but with a different index structure. See jmAttributeTable for further details. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmMirrorAttrTable." ::= { jmMirror 1 } jmMirrorAttrEntry OBJECT-TYPE SYNTAX JmMirrorAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attributes that represent information about each job and documents or resources required and/or consumed. Each entry in jmMirrorAttrTable is a per-attribute entry with a primary index for each type of attribute (jmMirrorAttrTypeIndex) that a job can have and secondary indices which specify job set (jmJobSetIndex), job instance (jmJobIndex), and attribute instance (jmMirrorAttrInstanceIndex). An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, jmMirrorAttrInstanceIndex } ::= { jmMirrorAttrTable 1 } JmMirrorAttrEntry ::= SEQUENCE { jmMirrorAttrTypeIndex JmAttributeTypeTC, jmMirrorAttrInstanceIndex Integer32 (1..32767), jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) } jmMirrorAttrTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. See jmAttributeTypeIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 1 } jmMirrorAttrInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of attribute that this row entry represents. See jmAttributeInstanceIndex in jmAttributeTable for complete description." ::= { jmMirrorAttrEntry 2 } jmMirrorAttrValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. See jmAttributeValueAsInteger in jmAttributeTable for complete description." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmMirrorAttrEntry 3 } jmMirrorAttrValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The octet string value of the attribute. See jmAttributeValueAsOctets in jmAttributeTable for complete description." DEFVAL { ''H } -- empty string ::= { jmMirrorAttrEntry 4 } ------------------------------------------------------------------------ [for placement in 'jmMIBCompliance' before the first OBJECT clause] GROUP jmMirrorAttrGroup DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ------------------------------------------------------------------------ [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] jmMirrorAttrGroup OBJECT-GROUP OBJECTS { jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } STATUS current DESCRIPTION "The mirror attribute group (sorted by attribute type). Implementation of this group is OPTIONAL. An agent which implements the jmMirrorAttrTable SHALL create and maintain a row in the jmMirrorAttrTable for each corresponding row in the jmAttributeTable." ::= { jmMIBGroups 5 } ------------------------------------------------------------------------ From rbergma at dpc.com Mon Nov 2 16:44:41 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribu In-Reply-To: <5030050023017534000002L542*@MHS> Message-ID: Harry, I agree! Good change! Ron On Mon, 2 Nov 1998, Harry Lewis wrote: > I agree with the addition of an OPTIONAL mirror attribute table and accept > Ron's modifications. I'd like to propose one MINOR change, myself... > > Rather than > -- The jmMirrorAttrTable provides efficient access to all of the > -- attributes that an implementation supports, sorted by attribute > -- type (traditional SNMP MIB access), rather than being sorted by > -- job set and job index (modern object-oriented access) as in the > -- analogous jmAttributeTable. > > I request deletion of the word "efficient" in the above. I think, > when we developed the tables we have, we did so because we felt it > was efficient. I think both methods are efficient based on > different perspectives and, therefor, there is no need to > embellish the paragraph. > > > Harry Lewis - IBM Printing Systems > harryl@us.ibm.com > > > > jmp-owner@pwg.org on 11/01/98 10:26:53 PM > Please respond to jmp-owner@pwg.org > To: hastings@cp10.es.xerox.com > cc: jmp@pwg.org > Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribu > > > Tom, > > I support your proposal to add the optional mirror attribute table to the > Job MIB. However, I would like to suggest the following text in place of > your proposed text. My changes eliminate much of the very repetitive text > that was included in your original draft. > > Also, you state that section 3.3 contains a description of > jmMirrorAttrTable, but you did not provide any changes to this section > with this description. (My revised text still contains this reference.) > > > Ron Bergman > Dataproducts Corp. > > > > ------------------------------------------------------------------------ > -- The Mirror Attribute Group (OPTIONAL) > > -- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. > -- > -- Implementation of the objects in this group is OPTIONAL. > -- See Section 3.1 entitled 'Conformance Considerations'. > -- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. > -- > -- The jmMirrorAttrTable provides efficient access to all of the > -- attributes that an implementation supports, sorted by attribute > -- type (traditional SNMP MIB access), rather than being sorted by > -- job set and job index (modern object-oriented access) as in the > -- analogous jmAttributeTable. > > jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } > > jmMirrorAttrTable OBJECT-TYPE > SYNTAX SEQUENCE OF JmAttributeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The jmMirrorAttrTable is an OPTIONAL table which provides > identical attributes to the jmAttributeTable but with a > different index structure. See jmAttributeTable for further > details. > > See Section 3.3 entitled 'The Attribute Mechanism' for a > description of the jmMirrorAttrTable." > ::= { jmMirror 1 } > > jmMirrorAttrEntry OBJECT-TYPE > SYNTAX JmMirrorAttrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The attributes that represent information about each job > and documents or resources required and/or consumed. > > Each entry in jmMirrorAttrTable is a per-attribute entry with a > primary index for each type of attribute (jmMirrorAttrTypeIndex) > that a job can have and secondary indices which specify job > set (jmJobSetIndex), job instance (jmJobIndex), and attribute > instance (jmMirrorAttrInstanceIndex). > > An agent which implements the jmMirrorAttrTable SHALL create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, > jmMirrorAttrInstanceIndex } > ::= { jmMirrorAttrTable 1 } > > JmMirrorAttrEntry ::= SEQUENCE { > jmMirrorAttrTypeIndex JmAttributeTypeTC, > jmMirrorAttrInstanceIndex Integer32 (1..32767), > jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), > jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) > } > > jmMirrorAttrTypeIndex OBJECT-TYPE > SYNTAX JmAttributeTypeTC > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The type of attribute that this row entry represents. > > See jmAttributeTypeIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 1 } > > jmMirrorAttrInstanceIndex OBJECT-TYPE > SYNTAX Integer32 (1..32767) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The instance of attribute that this row entry represents. > > See jmAttributeInstanceIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 2 } > > jmMirrorAttrValueAsInteger OBJECT-TYPE > SYNTAX Integer32 (-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The integer value of the attribute. > > See jmAttributeValueAsInteger in jmAttributeTable for complete > description." > DEFVAL { -2 } -- default value is unknown(-2) > ::= { jmMirrorAttrEntry 3 } > > jmMirrorAttrValueAsOctets OBJECT-TYPE > SYNTAX OCTET STRING(SIZE(0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The octet string value of the attribute. > > See jmAttributeValueAsOctets in jmAttributeTable for complete > description." > DEFVAL { ''H } -- empty string > ::= { jmMirrorAttrEntry 4 } > > ------------------------------------------------------------------------ > [for placement in 'jmMIBCompliance' before the first OBJECT clause] > > GROUP jmMirrorAttrGroup > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > > ------------------------------------------------------------------------ > [for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] > > jmMirrorAttrGroup OBJECT-GROUP > OBJECTS { > jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } > STATUS current > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > ::= { jmMIBGroups 5 } > > ------------------------------------------------------------------------ > > > > > > From imcdonal at eso.mc.xerox.com Mon Nov 2 17:31:12 1998 From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribu Message-ID: <9811022231.AA17097@snorkel.eso.mc.xerox.com> Ron and Harry, I agree with both of your clarifications. Ron, thanks for your editorial work for clarity. Thanks to you both for public support. Harry, what Tom and I said poorly was efficient access by either sort (jmMirrorAttributeTable for type and jmAttributeTable for job index). Your deletion was appropriate. Cheers, - Ira McDonald High North Inc 906-494-2434 From hastings at cp10.es.xerox.com Fri Nov 6 15:03:07 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute ta ble Message-ID: <918C79AB552BD211A2BD00805F15CE854B4AAB@x-crt-es-ms1.cp10.es.xerox.com> I agree with Harry and Ron to delete the word "efficient". I agree with Ron's shortening of the text. Always good to make it shorter. Yes, we need a short paragraph for Section 3.3. The only quibble is that we need to add back the phrase "for the same time". Else it isn't clear that rows in both tables have to come and go at the same time. See below. Should I edit this OPTIONAL table into the JMP MIB now or wait for discussion/agreement at the meeting next Tuesday? I'll be bringing ten copies to the meeting of the updated MIB with the other agreements we reached, so I could add this too. Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Monday, November 02, 1998 09:05 >To: Hastings, Tom N >Cc: jmp >Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribute >table > > >Tom, > >I support your proposal to add the optional mirror attribute >table to the >Job MIB. However, I would like to suggest the following text >in place of >your proposed text. My changes eliminate much of the very >repetitive text >that was included in your original draft. > >Also, you state that section 3.3 contains a description of >jmMirrorAttrTable, but you did not provide any changes to this section >with this description. (My revised text still contains this >reference.) > > > Ron Bergman > Dataproducts Corp. > > > >--------------------------------------------------------------- >--------- >-- The Mirror Attribute Group (OPTIONAL) > >-- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. >-- >-- Implementation of the objects in this group is OPTIONAL. >-- See Section 3.1 entitled 'Conformance Considerations'. >-- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. >-- >-- The jmMirrorAttrTable provides efficient access to all of the >-- attributes that an implementation supports, sorted by attribute >-- type (traditional SNMP MIB access), rather than being sorted by >-- job set and job index (modern object-oriented access) as in the >-- analogous jmAttributeTable. > >jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } > >jmMirrorAttrTable OBJECT-TYPE > SYNTAX SEQUENCE OF JmAttributeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The jmMirrorAttrTable is an OPTIONAL table which provides > identical attributes to the jmAttributeTable but with a > different index structure. See jmAttributeTable for further > details. > > See Section 3.3 entitled 'The Attribute Mechanism' for a > description of the jmMirrorAttrTable." > ::= { jmMirror 1 } > >jmMirrorAttrEntry OBJECT-TYPE > SYNTAX JmMirrorAttrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The attributes that represent information about each job > and documents or resources required and/or consumed. > > Each entry in jmMirrorAttrTable is a per-attribute entry with a > primary index for each type of attribute >(jmMirrorAttrTypeIndex) > that a job can have and secondary indices which specify job > set (jmJobSetIndex), job instance (jmJobIndex), and attribute > instance (jmMirrorAttrInstanceIndex). > > An agent which implements the jmMirrorAttrTable SHALL >create and > maintain a row in the jmMirrorAttrTable for each corresponding Replace the above line with: maintain a row in the jmMirrorAttrTable for the same time as each corresponding > row in the jmAttributeTable." > INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, > jmMirrorAttrInstanceIndex } > ::= { jmMirrorAttrTable 1 } > >JmMirrorAttrEntry ::= SEQUENCE { > jmMirrorAttrTypeIndex JmAttributeTypeTC, > jmMirrorAttrInstanceIndex Integer32 (1..32767), > jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), > jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) >} > >jmMirrorAttrTypeIndex OBJECT-TYPE > SYNTAX JmAttributeTypeTC > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The type of attribute that this row entry represents. > > See jmAttributeTypeIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 1 } > >jmMirrorAttrInstanceIndex OBJECT-TYPE > SYNTAX Integer32 (1..32767) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The instance of attribute that this row entry represents. > > See jmAttributeInstanceIndex in jmAttributeTable for complete > description." > ::= { jmMirrorAttrEntry 2 } > >jmMirrorAttrValueAsInteger OBJECT-TYPE > SYNTAX Integer32 (-2..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The integer value of the attribute. > > See jmAttributeValueAsInteger in jmAttributeTable for complete > description." > DEFVAL { -2 } -- default value is unknown(-2) > ::= { jmMirrorAttrEntry 3 } > >jmMirrorAttrValueAsOctets OBJECT-TYPE > SYNTAX OCTET STRING(SIZE(0..63)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The octet string value of the attribute. > > See jmAttributeValueAsOctets in jmAttributeTable for complete > description." > DEFVAL { ''H } -- empty string > ::= { jmMirrorAttrEntry 4 } > >--------------------------------------------------------------- >--------- >[for placement in 'jmMIBCompliance' before the first OBJECT clause] > > GROUP jmMirrorAttrGroup > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL >create and > maintain a row in the jmMirrorAttrTable for each corresponding Replace the above line with: maintain a row in the jmMirrorAttrTable for the same time as each corresponding > row in the jmAttributeTable." > >--------------------------------------------------------------- >--------- >[for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] > >jmMirrorAttrGroup OBJECT-GROUP > OBJECTS { > jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } > STATUS current > DESCRIPTION > "The mirror attribute group (sorted by attribute type). > Implementation of this group is OPTIONAL. > > An agent which implements the jmMirrorAttrTable SHALL >create and > maintain a row in the jmMirrorAttrTable for each corresponding > row in the jmAttributeTable." > ::= { jmMIBGroups 5 } > >--------------------------------------------------------------- >--------- > > > > From rbergma at dpc.com Fri Nov 6 15:32:33 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Proposal for addition of an OPTIONAL mirror attribute ta ble In-Reply-To: <918C79AB552BD211A2BD00805F15CE854B4AAB@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: Tom, Please add the mirror table to the draft and we can discuss further next week. As far as ther phrase "for the same time" being necessary, I disagree. In re-reading the text I don't see how it could interpreted any other way without this phrase. Again, we can discuss next week. Ron Bergman Dataproducts Corp. On Fri, 6 Nov 1998, Hastings, Tom N wrote: > I agree with Harry and Ron to delete the word "efficient". > > I agree with Ron's shortening of the text. Always good to make it shorter. > > Yes, we need a short paragraph for Section 3.3. > > The only quibble is that we need to add back the phrase "for the same time". > Else it isn't clear that rows in both tables have to come and go at the same > time. See below. > > Should I edit this OPTIONAL table into the JMP MIB now or wait for > discussion/agreement at the meeting next Tuesday? > > I'll be bringing ten copies to the meeting of the updated MIB with the other > agreements we reached, so I could add this too. > > Tom > > >-----Original Message----- > >From: Ron Bergman [mailto:rbergma@dpc.com] > >Sent: Monday, November 02, 1998 09:05 > >To: Hastings, Tom N > >Cc: jmp > >Subject: Re: JMP> Proposal for addition of an OPTIONAL mirror attribute > >table > > > > > >Tom, > > > >I support your proposal to add the optional mirror attribute > >table to the > >Job MIB. However, I would like to suggest the following text > >in place of > >your proposed text. My changes eliminate much of the very > >repetitive text > >that was included in your original draft. > > > >Also, you state that section 3.3 contains a description of > >jmMirrorAttrTable, but you did not provide any changes to this section > >with this description. (My revised text still contains this > >reference.) > > > > > > Ron Bergman > > Dataproducts Corp. > > > > > > > >--------------------------------------------------------------- > >--------- > >-- The Mirror Attribute Group (OPTIONAL) > > > >-- The jmMirrorAttrGroup consists entirely of the jmMirrorAttrTable. > >-- > >-- Implementation of the objects in this group is OPTIONAL. > >-- See Section 3.1 entitled 'Conformance Considerations'. > >-- The jmMirrorAttrTable complements the MANDATORY jmAttributeTable. > >-- > >-- The jmMirrorAttrTable provides efficient access to all of the > >-- attributes that an implementation supports, sorted by attribute > >-- type (traditional SNMP MIB access), rather than being sorted by > >-- job set and job index (modern object-oriented access) as in the > >-- analogous jmAttributeTable. > > > >jmMirrorAttr OBJECT IDENTIFIER ::= { jobmonMIBObjects 5 } > > > >jmMirrorAttrTable OBJECT-TYPE > > SYNTAX SEQUENCE OF JmAttributeEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The jmMirrorAttrTable is an OPTIONAL table which provides > > identical attributes to the jmAttributeTable but with a > > different index structure. See jmAttributeTable for further > > details. > > > > See Section 3.3 entitled 'The Attribute Mechanism' for a > > description of the jmMirrorAttrTable." > > ::= { jmMirror 1 } > > > >jmMirrorAttrEntry OBJECT-TYPE > > SYNTAX JmMirrorAttrEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The attributes that represent information about each job > > and documents or resources required and/or consumed. > > > > Each entry in jmMirrorAttrTable is a per-attribute entry with a > > primary index for each type of attribute > >(jmMirrorAttrTypeIndex) > > that a job can have and secondary indices which specify job > > set (jmJobSetIndex), job instance (jmJobIndex), and attribute > > instance (jmMirrorAttrInstanceIndex). > > > > An agent which implements the jmMirrorAttrTable SHALL > >create and > > maintain a row in the jmMirrorAttrTable for each corresponding > Replace the above line with: > > maintain a row in the jmMirrorAttrTable for the same time as each > corresponding > > > row in the jmAttributeTable." > > INDEX { jmMirrorAttrTypeIndex, jmGeneralJobSetIndex, jmJobIndex, > > jmMirrorAttrInstanceIndex } > > ::= { jmMirrorAttrTable 1 } > > > >JmMirrorAttrEntry ::= SEQUENCE { > > jmMirrorAttrTypeIndex JmAttributeTypeTC, > > jmMirrorAttrInstanceIndex Integer32 (1..32767), > > jmMirrorAttrValueAsInteger Integer32 (-2..2147483647), > > jmMirrorAttrValueAsOctets OCTET STRING(SIZE(0..63)) > >} > > > >jmMirrorAttrTypeIndex OBJECT-TYPE > > SYNTAX JmAttributeTypeTC > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The type of attribute that this row entry represents. > > > > See jmAttributeTypeIndex in jmAttributeTable for complete > > description." > > ::= { jmMirrorAttrEntry 1 } > > > >jmMirrorAttrInstanceIndex OBJECT-TYPE > > SYNTAX Integer32 (1..32767) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The instance of attribute that this row entry represents. > > > > See jmAttributeInstanceIndex in jmAttributeTable for complete > > description." > > ::= { jmMirrorAttrEntry 2 } > > > >jmMirrorAttrValueAsInteger OBJECT-TYPE > > SYNTAX Integer32 (-2..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The integer value of the attribute. > > > > See jmAttributeValueAsInteger in jmAttributeTable for complete > > description." > > DEFVAL { -2 } -- default value is unknown(-2) > > ::= { jmMirrorAttrEntry 3 } > > > >jmMirrorAttrValueAsOctets OBJECT-TYPE > > SYNTAX OCTET STRING(SIZE(0..63)) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The octet string value of the attribute. > > > > See jmAttributeValueAsOctets in jmAttributeTable for complete > > description." > > DEFVAL { ''H } -- empty string > > ::= { jmMirrorAttrEntry 4 } > > > >--------------------------------------------------------------- > >--------- > >[for placement in 'jmMIBCompliance' before the first OBJECT clause] > > > > GROUP jmMirrorAttrGroup > > DESCRIPTION > > "The mirror attribute group (sorted by attribute type). > > Implementation of this group is OPTIONAL. > > > > An agent which implements the jmMirrorAttrTable SHALL > >create and > > maintain a row in the jmMirrorAttrTable for each corresponding > Replace the above line with: > > maintain a row in the jmMirrorAttrTable for the same time as each > corresponding > > > > row in the jmAttributeTable." > > > >--------------------------------------------------------------- > >--------- > >[for placement after the 'jmMIBCompliance' MODULE-COMPLIANCE macro] > > > >jmMirrorAttrGroup OBJECT-GROUP > > OBJECTS { > > jmMirrorAttrValueAsInteger, jmMirrorAttrValueAsOctets } > > STATUS current > > DESCRIPTION > > "The mirror attribute group (sorted by attribute type). > > Implementation of this group is OPTIONAL. > > > > An agent which implements the jmMirrorAttrTable SHALL > >create and > > maintain a row in the jmMirrorAttrTable for each corresponding > > row in the jmAttributeTable." > > ::= { jmMIBGroups 5 } > > > >--------------------------------------------------------------- > >--------- > > > > > > > > > From hastings at cp10.es.xerox.com Mon Nov 9 17:59:10 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> I've posted JMP MIB V1.3 - with IESG fixes and mirror table Message-ID: <918C79AB552BD211A2BD00805F15CE854B4CA4@x-crt-es-ms1.cp10.es.xerox.com> I haven't had time to compile it or produce a .txt form: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf I'll bring 10 copies to the meeting tomorrow. Here is the change history: 1.1 Changes to produce version 1.3, dated November 8, 1998 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.3, dated November 8, 1998: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. Tom Hastings (310) 333-6413 From don at lexmark.com Fri Nov 20 15:20:51 1998 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Re: Maui Meeting Message-ID: <199811202024.AA18677@interlock2.lexmark.com> At the request of Ron Bergman and Harry Lewis, there are no MIB meetings planned for Maui. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** kpalmer%duplousa.com@interlock.lexmark.com on 11/19/98 08:02:43 PM Please respond to kpalmer%duplousa.com@interlock.lexmark.com To: Don Wright@LEXMARK cc: Subject: Maui Meeting Don: Do you know what days and times we will have the MIB meetings? Thank you Kevin Palmer Duplo USA Corp. From harryl at us.ibm.com Fri Nov 20 15:39:55 1998 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:00:16 2009 Subject: JMP> Re: PMP> Re: Maui Meeting Message-ID: <5030100028732577000002L072*@MHS> No MIB meetings, as such... but, as I pointed out in Tucson... there was a high likelihood that we would be addressing the Printer-Finisher interface. While this is not a MIB meeting (Don is correct)... it will likely be of interest to anyone who has been involved in the Printer, Finisher and Job MIB's, in the past. The agenda for Printer-Finisher interface in January is not set, yet... but, due to an expected large turn out overlaying with IEEE1394 on Thursday is under consideration. Harry Lewis - IBM Printing Systems harryl@us.ibm.com pmp-owner@pwg.org on 11/20/98 01:27:57 PM Please respond to pmp-owner@pwg.org To: kpalmer@duplousa.com cc: jmp@pwg.org, pmp@pwg.org, fin@pwg.org Subject: PMP> Re: Maui Meeting At the request of Ron Bergman and Harry Lewis, there are no MIB meetings planned for Maui. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** kpalmer%duplousa.com@interlock.lexmark.com on 11/19/98 08:02:43 PM Please respond to kpalmer%duplousa.com@interlock.lexmark.com To: Don Wright@LEXMARK cc: Subject: Maui Meeting Don: Do you know what days and times we will have the MIB meetings? Thank you Kevin Palmer Duplo USA Corp. From rbergma at dpc.com Mon Nov 23 11:08:04 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Object to Indicate MIB Revision Message-ID: An additional object for the Job MIB, that would indicate the version of the MIB implemented, was discussed at the Tucson meeting. Now two weeks later there has not been a formal proposal submitted to the mail list. Upon further pondering of the proposal, I have concluded that this additional object would have marginal value. (No other MIB, that I am aware of, includes such an object.) I would like to get this project back on track and submit the updated document to the IESG as soon as possible. I do not want this effort to turn into a long term research project. I suggest that the document be frozen as presented in Tucson and the last call start immediately. Comments? Ron Bergman Dataproducts Corp. From harryl at us.ibm.com Mon Nov 23 12:41:34 1998 From: harryl at us.ibm.com (harryl@us.ibm.com) Date: Wed May 6 14:00:16 2009 Subject: JMP> Object to Indicate MIB Revision Message-ID: <872566C5.00612AEC.00@us.ibm.com> I agree with Ron. The version was an attempt to figure a way to add the "mirror" table and make it mandatory. I propose this be handled in a future RFC, if necessary which can, at that time, add the version. Meanwhile, the mirror table can be optional. Harry Lewis - IBM Printing Systems harryl@us.ibm.com From hastings at cp10.es.xerox.com Mon Nov 23 12:54:53 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Object to Indicate MIB Revision Message-ID: <918C79AB552BD211A2BD00805F15CE85606AB4@x-crt-es-ms1.cp10.es.xerox.com> Sorry not to have made the proposal for the new version group sooner, but as editor of the IPP Model document, I have had my hands full getting that out by the deadline of last Wednesday. We seem to have forgotten the other object in this new group that we agreed to at the meeting, which is very useful to applications: A BITS vector that indicates which attributes have been implemented. Then an application can know whether to ever expect certain attributes to appear or not. I agree that we don't want to turn the JMP MIB into a research project. On the other hand, our developers had previously suggested just such a BITS vector, so I was very supportive of the proposal when it was brought up at the Tucson meeting. I'll make the proposal today. Tom >-----Original Message----- >From: Ron Bergman [mailto:rbergma@dpc.com] >Sent: Monday, November 23, 1998 08:08 >To: jmp@pwg.org >Subject: JMP> Object to Indicate MIB Revision > > >An additional object for the Job MIB, that would indicate the >version of >the MIB implemented, was discussed at the Tucson meeting. Now >two weeks >later there has not been a formal proposal submitted to the mail list. > >Upon further pondering of the proposal, I have concluded that this >additional object would have marginal value. (No other MIB, that I am >aware of, includes such an object.) > >I would like to get this project back on track and submit the updated >document to the IESG as soon as possible. I do not want this effort to >turn into a long term research project. > >I suggest that the document be frozen as presented in Tucson >and the last >call start immediately. > >Comments? > > > Ron Bergman > Dataproducts Corp. > > From hastings at cp10.es.xerox.com Wed Nov 25 15:42:22 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Job Monitoring MIB V1.3 posted Message-ID: <918C79AB552BD211A2BD00805F15CE85606D38@x-crt-es-ms1.cp10.es.xerox.com> I've posted the 1.3 JMP MIB as agreed in Tucson as: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib-rev.pdf It compiles. The .mib file is the result of stripping the headers. If Ron agrees, it is ready for him to send out to the PWG-ANNOUNCE mailing list for PWG Last Call. The .txt file should be renamed to: draft-ietf-printmib-job-monitor-08.txt when we send it as an Internet-Draft. I did NOT post it in the Internet-Drafts directory yet on the PWG server and did NOT send it to the IETF. (The IETF isn't accepting I-Ds until after their meeting in December. Here is the change history: 1.1 Changes to produce version 1.3, dated November 8, 1998 The following changes were made to version 1.2, dated October 2, 1998 to make version 1.3, dated November 8, 1998: 1. Added the Mirror table. 2. Moved the JmJobSubmissionIDTypeTC, JmJobStateReasons1TC, JmJobStateReasons2TC, JmJobStateReasons3TC, and JmJobStateReasons4TC assignments out of the MIB and into the Introduction. 3. Added the MANDATORY jmSystemGroup that contains the jmSystemVersionString, jmSystemOptionSupport, and jmSystemAttributeSupport objects. Here is the new System Group that we discussed adding in Tucson to help a management application determine what parts of the MIB the agent was supporting: -- The System Group (MANDATORY) -- (This group was added in version 1.3 of this MIB). -- The jmMirrorAttrGroup consists entirely of objects that summarize -- the implementation of this MIB on a system. jmSystem OBJECT IDENTIFIER ::= { jobmonMIBObjects 6 } jmSystemVersionString OBJECT-TYPE SYNTAX JmUTF8StringTC MAX-ACCESS read-only STATUS current DESCRIPTION "The minor and minor version of this MIB implemented by this system. The format of the string SHALL be the ASCII major version number followed by an ASCII PERIOD (.), followed by the ASCII minor version number, i.e., '1.3' for this version." DEFVAL { '312E33'H } -- version 1.3 ::= { jmSystem 1 } jmSystemOptionSupport OBJECT-TYPE SYNTAX INTEGER(0..2147483647) -- biggest int 2**31 - 1 MAX-ACCESS read-only STATUS current DESCRIPTION "The options of the MIB specification that this implementation supports specified as a bit mask. The current set of values (which may be extended in the future) is given below: 1 : jmMirrorAttrGroup -- 2**0 OPTIONAL Example: An implementation supporting the jmMirrorAttrGroup would return an integer value of { 1 }. This object helps a management application determine which MIB options are supported in this system." DEFVAL { 0 } -- no options are required ::= { jmSystem 2 } jmSystemAttributeSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The attributes of the MIB that this implementation supports specified as a bit array. The value of this object is a sparse bit array in which bit n is present if attribute n is supported, where n is the value of the enumerated attribute type in the JmAttributeTypeTC used in jmAttributeTypeIndex (and the jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). The high order bit of the first octet in this octet string corresponds to an attribute type of 0 (reserved), i.e., Big Endian bit string. Compare with the BITS data type in SMIv2 [SMIv2-SMI] which has the same format but requires contiguous enumerated bits. Note: private attributes cannot be represented in this bit array because their enum values are in the range 2**30 to 2**31-1. See section 3.3.8. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a value of { '180001'H }. This object helps a management application determine which attributes MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 3 } Tom Hastings (310) 333-6413 From hastings at cp10.es.xerox.com Mon Dec 14 18:47:58 1998 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:00:16 2009 Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call Message-ID: <918C79AB552BD211A2BD00805F15CE8572F270@x-crt-es-ms1.cp10.es.xerox.com> We held a Xerox-wide design review the proposed version 1.3 of the PWG Job Monitoring MIB that included a number of client-side developers as well as agent developers. We believe that the single bit array, jmSystemAttributeSupport, indicating attribute support should be replaced with three bit arrays: 1) A bit array specifying which supported attributes can contain meaningful integer data. 2) A bit array specifying which supported attributes can contain meaningful string data. 3) A bit array specifying which supported attributes can have more than one integer or more than one string value. There are two main areas of concern regarding the use of "dictionary" or attribute defining MIBs. First is the efficiency with which attribute values can be requested and obtained from the device and second is the ability to create generic management middleware that can be reused when the MIB is extended with additional attributes and can be used with different management applications that use different combinations of attributes. Such middleware obtains all of the attributes and keeps a local copy of the attributes updated as the device runs. Any management application then deals with the client-side local copy by calling the client-side management middleware for any combination of attributes which are returned immediately without querying the device. Some items of note which should be considered in the following discussion are: 1) Most management applications must support SNMPv1 and SNMPv2 so that relying on a getBulk type operation is not viable. 2) Most management applications support multiple SNMP protocol stacks some of which have quite small packet size limits such as 480 octets so relying on a maximum size of more than that is not viable. One of the major concerns of many management applications is the minimization of network traffic and a major factor in determining the amount of traffic is the number of strings to be retrieved. The reason for this is due to the fact that strings can be fairly long, up to 63 octets. Couple this with the limited packet size available and it is easily seen that if a large number of strings are to be retrieved then a large number of packets will be required. At most only 6 strings can be requested in a single packet, else there is the risk of not all of the data fitting in the packet. This is because each string can be up to 63 octets and the OID for each string can be around 15-20 octets, say around 80 as a maximum. 484 divided by 80 is 6 strings maximum. If only a single bit array is used then both the integer and string values will have to be requested for all of the supported attributes. Since most of the string values will be NULL this results in a large number of packets with unnecessary data (the null strings). With an indicator of which attributes can actually have valid string data then only those attributes need to be requested and the number of needed packets can be optimized. This same argument applies to integers as well, although, to a lesser degree since 24 or so integers can be requested in a single packet. Being able to request this information from the device rather than encoding it directly into management application middleware makes the application middleware more robust, generic and re-usable. Encoding the information directly into the application middleware that an application needs means that the middleware can not be used with any application. It also means that if new attributes are added to a MIB then the application middleware will have to be modified to accommodate them. Neither of these situations is desirable from a software design and product deployment point-of-view. Adding the bit array that indicates which attributes might have more than one value and which ones cannot, means that the management application knows which values should be retrieved with several GetNext operations in order to pick up all the values and which only need one direct Get. While the specification indicates which attribute MAY have multiple values, many implementations MAY only actually implement one value. For example, the number of fileName or documentName attribute values per job MAY only have a single value for many implementations that only support one document per job, though multiple values are allowed. The same for mediumRequested, etc. So the third bit array indicates which attributes could have more than one value for that implementation. Having these three bit arrays also allows management middleware to obtain attribute extensions from a device that were registered after the management middleware was shipped. Only the management application needs updating that wants to take advantage of the newly registered attributes. Since these bit arrays are all read-only and never change while the device operates, they are very low cost in implementation and can be put into ROM. While we share the group's concern about "creeping elegance" and "mission creep" and want to see the PWG Job Monitoring MIB approved, we believe that these three bit arrays are the end. There does not seem to be any other support information about an implementation that could be added to the new System Group. So we believe that this addition would be the end. We have produced complete compilable alternatives to V1.3 and stored them in a sub-directory of the usual place: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .pdf Here are the relevant changes: In Section 3.3.8 Attribute Specification update the paragraphs on the bit array support: A management application can determine which attributes are supported and whether the integer and/or the octet string values are supported with meaningful value by querying the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects, respectively. Management applications can also determine which supported attributes might support more than one integer value or more than one octet string value by querying jmSystemAttrMultiRowSupport. These support bits are indicated in hex for each range in the line starting with "support bits starting:". Note: these objects permit a management application to determine the degree of support, even when there are no jobs present in the system. They also permit management middleware to fetch all attribute values for all jobs, including future extensions, and keep them updated for one or more management applications at the same time. Replace the jmSystemAttributeSupport bit array object with the following three bit array objects: jmSystemAttrIntegerSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful integer values. The value of this object is a sparse bit array in which bit n is a 1 if attribute n is supported with the jmAttributeValueAsInteger object with meaningful values, where n is the value of the enumerated attribute type in the JmAttributeTypeTC used in jmAttributeTypeIndex (and the jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned with a '- 1'(other) or '-2'(unknown) value. The high order bit of the first octet in this octet string corresponds to an attribute type of 0 (reserved), i.e., the bit string uses the Big Endian numbering convention. Compare with the BITS data type in SMIv2 [SMIv2-SMI] which has the same format but requires contiguous enumerated bits. Trailing octets in the octet string that contain only zero bits MUST NOT be returned. Note: private attributes cannot be represented in this bit array because their enum values are in the range 2**30 to 2**31-1. See section 3.3.8. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a one-octet string value of { '18'H }, since jobName is an octet string value, not an integer value. This object helps a management application determine which attributes with meaningful integer values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 3 } jmSystemAttrOctetsSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful octet string values. The format and semantics of this object is the same as jmSystemAttrIntegerSupport, except that bit n indicates that attribute n supports the jmAttributeValueAsOctets object with meaningful values, instead of the jmAttributeValueAsInteger object. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned as a zero-length octet string value. If an implementation supports both jmAttributeValueAsInteger and jmAttributeValueAsOctets with meaningful values for attribute n, bit n MUST appear in both bit array objects with a 1 value. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a three-octet string value of { '000001'H }, since jobStateReasons2 and jobStateReasons3 are integer values, not octet string values. This object helps a management application determine which attributes with meaningful octet string values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 4 } jmSystemAttrMultiRowSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which MULTI-ROW attributes of the MIB this implementation supports with multiple integer values and/or multiple octet string values. The format of this object is the same as the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects. Bit n MUST be 1, if attribute n is actually supported with more than one integer and/or more than one octet string value. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported, is always returned as a single integer value, or as a single octet string value. For every bit n that is a 1 in this bit array, there MUST be a corresponding 1 for bit n in either jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, or both. Example: Consider an implementation supporting: (a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW integer attributes (b) the jobName(23) SINGLE-ROW octet string attribute (c) more than one integer value for the mediumRequested(170) and mediumConsumed(171) MULTI-ROW attributes AND (d) more than one octet string value for the fileName(34), documentName(35), and mediumConsumed(171) MULTI-ROW attributes (e) no octet string values for mediumRequested(170). Such an implementation would return: jmSystemAttrIntegerSupport 22 octets: { '18000000 00000000 00000000 00000000 00000000 0030'H } jmSystemAttrOctetsSupport 22 octets: { '00000100 30000000 00000000 00000000 00000000 0010'H } jmSystemAttrMultiRowSupport 22 octets: { '00000000 30000000 00000000 00000000 00000000 0030'H } Example: Consider an implementation that supports the fileName(34) MULTI-ROW attribute, but does not support more than one document per job. Such an implementation would NOT return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since such an implementation would never return more than one fileName value for a job. It would return a zero-length string, since it never returns more than one value. This object helps a management application determine which attributes may return more than one integer value or more than one octet string value on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 5 } Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike Elvers, Ang Caruso, Joe Filion (310) 333-6413 From rbergma at dpc.com Tue Dec 22 10:41:31 1998 From: rbergma at dpc.com (Ron Bergman) Date: Wed May 6 14:00:16 2009 Subject: JMP> Ballot on Xerox Job MIB comments Message-ID: I am requesting a formal ballot regarding the recent request from Xerox to expand the object jmSystemAttributeSupport to three objects. Since this is a very last minute change, it is very important that all who have participated in this project review this change carefully. Please return the following ballot: Name: ___________________________________ Company: ________________________________ ___ I support this proposed change ___ I reject this proposed change ___ I abstain from voting for the following reason: ___________________________________________________________ Because the holidays will soon be here, I am setting the deadline to January 13th. So we should have a final vote prior to the Maui meeting. I encourage everyone to vote! Ron Bergman Dataproducts Corp. ---------- Forwarded message ---------- Date: Mon, 14 Dec 1998 15:47:58 -0800 From: "Hastings, Tom N" To: jmp Subject: JMP> Xerox comments on PWG Job Monitoring MIB Last Call We held a Xerox-wide design review the proposed version 1.3 of the PWG Job Monitoring MIB that included a number of client-side developers as well as agent developers. We believe that the single bit array, jmSystemAttributeSupport, indicating attribute support should be replaced with three bit arrays: 1) A bit array specifying which supported attributes can contain meaningful integer data. 2) A bit array specifying which supported attributes can contain meaningful string data. 3) A bit array specifying which supported attributes can have more than one integer or more than one string value. There are two main areas of concern regarding the use of "dictionary" or attribute defining MIBs. First is the efficiency with which attribute values can be requested and obtained from the device and second is the ability to create generic management middleware that can be reused when the MIB is extended with additional attributes and can be used with different management applications that use different combinations of attributes. Such middleware obtains all of the attributes and keeps a local copy of the attributes updated as the device runs. Any management application then deals with the client-side local copy by calling the client-side management middleware for any combination of attributes which are returned immediately without querying the device. Some items of note which should be considered in the following discussion are: 1) Most management applications must support SNMPv1 and SNMPv2 so that relying on a getBulk type operation is not viable. 2) Most management applications support multiple SNMP protocol stacks some of which have quite small packet size limits such as 480 octets so relying on a maximum size of more than that is not viable. One of the major concerns of many management applications is the minimization of network traffic and a major factor in determining the amount of traffic is the number of strings to be retrieved. The reason for this is due to the fact that strings can be fairly long, up to 63 octets. Couple this with the limited packet size available and it is easily seen that if a large number of strings are to be retrieved then a large number of packets will be required. At most only 6 strings can be requested in a single packet, else there is the risk of not all of the data fitting in the packet. This is because each string can be up to 63 octets and the OID for each string can be around 15-20 octets, say around 80 as a maximum. 484 divided by 80 is 6 strings maximum. If only a single bit array is used then both the integer and string values will have to be requested for all of the supported attributes. Since most of the string values will be NULL this results in a large number of packets with unnecessary data (the null strings). With an indicator of which attributes can actually have valid string data then only those attributes need to be requested and the number of needed packets can be optimized. This same argument applies to integers as well, although, to a lesser degree since 24 or so integers can be requested in a single packet. Being able to request this information from the device rather than encoding it directly into management application middleware makes the application middleware more robust, generic and re-usable. Encoding the information directly into the application middleware that an application needs means that the middleware can not be used with any application. It also means that if new attributes are added to a MIB then the application middleware will have to be modified to accommodate them. Neither of these situations is desirable from a software design and product deployment point-of-view. Adding the bit array that indicates which attributes might have more than one value and which ones cannot, means that the management application knows which values should be retrieved with several GetNext operations in order to pick up all the values and which only need one direct Get. While the specification indicates which attribute MAY have multiple values, many implementations MAY only actually implement one value. For example, the number of fileName or documentName attribute values per job MAY only have a single value for many implementations that only support one document per job, though multiple values are allowed. The same for mediumRequested, etc. So the third bit array indicates which attributes could have more than one value for that implementation. Having these three bit arrays also allows management middleware to obtain attribute extensions from a device that were registered after the management middleware was shipped. Only the management application needs updating that wants to take advantage of the newly registered attributes. Since these bit arrays are all read-only and never change while the device operates, they are very low cost in implementation and can be put into ROM. While we share the group's concern about "creeping elegance" and "mission creep" and want to see the PWG Job Monitoring MIB approved, we believe that these three bit arrays are the end. There does not seem to be any other support information about an implementation that could be added to the new System Group. So we believe that this addition would be the end. We have produced complete compilable alternatives to V1.3 and stored them in a sub-directory of the usual place: ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp.dic ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.mib ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.pdf ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib.txt ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .doc ftp://ftp.pwg.org/pub/pwg/jmp/mibs/ver-1.3-with-three-bit-arrays/jmp-mib-rev .pdf Here are the relevant changes: In Section 3.3.8 Attribute Specification update the paragraphs on the bit array support: A management application can determine which attributes are supported and whether the integer and/or the octet string values are supported with meaningful value by querying the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects, respectively. Management applications can also determine which supported attributes might support more than one integer value or more than one octet string value by querying jmSystemAttrMultiRowSupport. These support bits are indicated in hex for each range in the line starting with "support bits starting:". Note: these objects permit a management application to determine the degree of support, even when there are no jobs present in the system. They also permit management middleware to fetch all attribute values for all jobs, including future extensions, and keep them updated for one or more management applications at the same time. Replace the jmSystemAttributeSupport bit array object with the following three bit array objects: jmSystemAttrIntegerSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful integer values. The value of this object is a sparse bit array in which bit n is a 1 if attribute n is supported with the jmAttributeValueAsInteger object with meaningful values, where n is the value of the enumerated attribute type in the JmAttributeTypeTC used in jmAttributeTypeIndex (and the jmMirrorAttrTypeIndex if the jmMirrorAttrTable is implemented). Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned with a '- 1'(other) or '-2'(unknown) value. The high order bit of the first octet in this octet string corresponds to an attribute type of 0 (reserved), i.e., the bit string uses the Big Endian numbering convention. Compare with the BITS data type in SMIv2 [SMIv2-SMI] which has the same format but requires contiguous enumerated bits. Trailing octets in the octet string that contain only zero bits MUST NOT be returned. Note: private attributes cannot be represented in this bit array because their enum values are in the range 2**30 to 2**31-1. See section 3.3.8. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a one-octet string value of { '18'H }, since jobName is an octet string value, not an integer value. This object helps a management application determine which attributes with meaningful integer values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 3 } jmSystemAttrOctetsSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which attributes of the MIB this implementation supports with meaningful octet string values. The format and semantics of this object is the same as jmSystemAttrIntegerSupport, except that bit n indicates that attribute n supports the jmAttributeValueAsOctets object with meaningful values, instead of the jmAttributeValueAsInteger object. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported or is always returned as a zero-length octet string value. If an implementation supports both jmAttributeValueAsInteger and jmAttributeValueAsOctets with meaningful values for attribute n, bit n MUST appear in both bit array objects with a 1 value. Example: An implementation supporting the attributes: jobStateReasons2(3), jobStateReasons3(4), and jobName(23) would return a three-octet string value of { '000001'H }, since jobStateReasons2 and jobStateReasons3 are integer values, not octet string values. This object helps a management application determine which attributes with meaningful octet string values MAY be present on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 4 } jmSystemAttrMultiRowSupport OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit array indicating which MULTI-ROW attributes of the MIB this implementation supports with multiple integer values and/or multiple octet string values. The format of this object is the same as the jmSystemAttrIntegerSupport and jmSystemAttrOctetsSupport objects. Bit n MUST be 1, if attribute n is actually supported with more than one integer and/or more than one octet string value. Bit n MUST be 0 (or beyond the end of the returned bit array), if attribute n is not supported, is always returned as a single integer value, or as a single octet string value. For every bit n that is a 1 in this bit array, there MUST be a corresponding 1 for bit n in either jmSystemAttrIntegerSupport, jmSystemAttrOctetsSupport, or both. Example: Consider an implementation supporting: (a) the jobStateReasons2(3), jobStateReasons3(4) SINGLE-ROW integer attributes (b) the jobName(23) SINGLE-ROW octet string attribute (c) more than one integer value for the mediumRequested(170) and mediumConsumed(171) MULTI-ROW attributes AND (d) more than one octet string value for the fileName(34), documentName(35), and mediumConsumed(171) MULTI-ROW attributes (e) no octet string values for mediumRequested(170). Such an implementation would return: jmSystemAttrIntegerSupport 22 octets: { '18000000 00000000 00000000 00000000 00000000 0030'H } jmSystemAttrOctetsSupport 22 octets: { '00000100 30000000 00000000 00000000 00000000 0010'H } jmSystemAttrMultiRowSupport 22 octets: { '00000000 30000000 00000000 00000000 00000000 0030'H } Example: Consider an implementation that supports the fileName(34) MULTI-ROW attribute, but does not support more than one document per job. Such an implementation would NOT return a 1 bit for bit 34 in jmSystemAttrMultiRowSupport, since such an implementation would never return more than one fileName value for a job. It would return a zero-length string, since it never returns more than one value. This object helps a management application determine which attributes may return more than one integer value or more than one octet string value on jobs in this system." DEFVAL { ''H } -- no attributes are required ::= { jmSystem 5 } Tom Hastings, Ira McDonald, Paul Gloger, Gary Padlipsky, Mike Elvers, Ang Caruso, Joe Filion (310) 333-6413