MFPA-96-057 >So, with all that said, let me restate the question using this new point >of view: > > If the printer supports say PostScript-I and PostScript-II "Control >Protocols", why do we need to make a distinction if these protocols are >handled by the same code and share much of the same data (i.e. in terms >of fonts, etc.)? > >If there is no real justification to this question, then you would not >need the new object/attribute that you are suggesting, Tom. Raymond, If this is the case, you are indicating that prtInterpreterLangLevel is satisfactory, as long as it is not ambiguous. Is this conclusion correct?? --- Binnur Al-Kazily Hewlett-Packard Company Integrated Network Solutions binnur@boi.hp.com (208)396-6372 KB7YWD DoD #2010 ---------- >So, with all that said, let me restate the question using this new point >of view: > > If the printer supports say PostScript-I and PostScript-II "Control >Protocols", why do we need to make a distinction if these protocols are >handled by the same code and share much of the same data (i.e. in terms >of fonts, etc.)? > >If there is no real justification to this question, then you would not >need the new object/attribute that you are suggesting, Tom. Raymond, If this is the case, you are indicating that prtInterpreterLangLevel is satisfactory, as long as it is not ambiguous. Is this conclusion correct?? --- Binnur Al-Kazily Hewlett-Packard Company Integrated Network Solutions binnur@boi.hp.com (208)396-6372 KB7YWD DoD #2010 ---------- Binnur: Yes, I agree that "PrtInterpreterLangLevel is sufficient as long as it is not ambiguous" is a good statement for most purposes. But, I can spot a position stating that it is not sufficient for all purposes. We have to look at this from the standpoint of migrating system versions. There are four possibilities based on the skew between the versions of the systems. First, to identify the systems, let's call the system containing the printer as P and the management station as MS. Consider a language that has versions X,Y,Z. A table can be constructed based on the knowledge of the systems. MS P Situation ----------- ----------- --------------------- Case 1) X,Y X,Y At Same Level Case 2) X,Y,Z X,Y Printer older than MS Case 3) X,Y X,Y,Z MS Older than Printer Case 4) X,Y Z MS Older than Printer Case 5) Z X,Y Printer Older than MS So, let's analyze the requirements for each case. Case 1,2,3) unambiguity is sufficient Case 4,5) unambiguity is insufficient So, Case 4 & 5 are the only time that we would need the other information advocated by Tom Hastings, i.e. (Case 4) the Management station would like to know that there is a chance that interpreter Z may be OK for job Y (or X). This situation only arises because P is not fully disclosing it's capabilities. In Case 5, we are given a job Z that claims that it uses the new file format Z. However, it is likely that it may work on X or Y, since Z is an improved version from Y. (Case 4) I think this is an outlier problem and should not govern the decision. It is reasonable to ask P to disclose its capabilities. (Case 5) I don't mind if the request fails due to this mismatch. If the user wants completion, he should select a supported format. I take this position with full knowledge that the file format MAY work. The override should be a user-controlled issue. Therefore, I suggest that your conclusion is in fact still a good one and that we should consider unambiguity sufficient. -Raymond At 08:26 AM 4/1/96 M, Binnur Al-Kazily wrote: > >>So, with all that said, let me restate the question using this new point >>of view: >> >> If the printer supports say PostScript-I and PostScript-II "Control >>Protocols", why do we need to make a distinction if these protocols are >>handled by the same code and share much of the same data (i.e. in terms >>of fonts, etc.)? >> >>If there is no real justification to this question, then you would not >>need the new object/attribute that you are suggesting, Tom. > >Raymond, > >If this is the case, you are indicating that prtInterpreterLangLevel is >satisfactory, as long as it is not ambiguous. Is this conclusion >correct?? > > --- >Binnur Al-Kazily Hewlett-Packard Company Integrated Network Solutions >binnur@boi.hp.com (208)396-6372 KB7YWD DoD #2010 > > > ---------- > > >So, with all that said, let me restate the question using this new point >of view: > > If the printer supports say PostScript-I and PostScript-II "Control >Protocols", why do we need to make a distinction if these protocols are >handled by the same code and share much of the same data (i.e. in terms >of fonts, etc.)? > >If there is no real justification to this question, then you would not >need the new object/attribute that you are suggesting, Tom. Raymond, If this is the case, you are indicating that prtInterpreterLangLevel is satisfactory, as long as it is not ambiguous. Is this conclusion correct?? --- Binnur Al-Kazily Hewlett-Packard Company Integrated Network Solutions binnur@boi.hp.com (208)396-6372 KB7YWD DoD #2010 ---------- Binnur: Yes, I agree that "PrtInterpreterLangLevel is sufficient as long as it is not ambiguous" is a good statement for most purposes. But, I can spot a position stating that it is not sufficient for all purposes. We have to look at this from the standpoint of migrating system versions. There are four possibilities based on the skew between the versions of the systems. First, to identify the systems, let's call the system containing the printer as P and the management station as MS. Consider a language that has versions X,Y,Z. A table can be constructed based on the knowledge of the systems. MS P Situation ----------- ----------- --------------------- Case 1) X,Y X,Y At Same Level Case 2) X,Y,Z X,Y Printer older than MS Case 3) X,Y X,Y,Z MS Older than Printer Case 4) X,Y Z MS Older than Printer Case 5) Z X,Y Printer Older than MS So, let's analyze the requirements for each case. Case 1,2,3) unambiguity is sufficient Case 4,5) unambiguity is insufficient So, Case 4 & 5 are the only time that we would need the other information advocated by Tom Hastings, i.e. (Case 4) the Management station would like to know that there is a chance that interpreter Z may be OK for job Y (or X). This situation only arises because P is not fully disclosing it's capabilities. In Case 5, we are given a job Z that claims that it uses the new file format Z. However, it is likely that it may work on X or Y, since Z is an improved version from Y. (Case 4) I think this is an outlier problem and should not govern the decision. It is reasonable to ask P to disclose its capabilities. (Case 5) I don't mind if the request fails due to this mismatch. If the user wants completion, he should select a supported format. I take this position with full knowledge that the file format MAY work. The override should be a user-controlled issue. Therefore, I suggest that your conclusion is in fact still a good one and that we should consider unambiguity sufficient. -Raymond At 08:26 AM 4/1/96 M, Binnur Al-Kazily wrote: > >>So, with all that said, let me restate the question using this new point >>of view: >> >> If the printer supports say PostScript-I and PostScript-II "Control >>Protocols", why do we need to make a distinction if these protocols are >>handled by the same code and share much of the same data (i.e. in terms >>of fonts, etc.)? >> >>If there is no real justification to this question, then you would not >>need the new object/attribute that you are suggesting, Tom. > >Raymond, > >If this is the case, you are indicating that prtInterpreterLangLevel is >satisfactory, as long as it is not ambiguous. Is this conclusion >correct?? > > --- >Binnur Al-Kazily Hewlett-Packard Company Integrated Network Solutions >binnur@boi.hp.com (208)396-6372 KB7YWD DoD #2010 > > > ---------- > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Binnur: Yes, I agree that "PrtInterpreterLangLevel is sufficient as long as it is not ambiguous" is a good statement for most purposes. But, I can spot a position stating that it is not sufficient for all purposes. We have to look at this from the standpoint of migrating system versions. There are four possibilities based on the skew between the versions of the systems. First, to identify the systems, let's call the system containing the printer as P and the management station as MS. Consider a language that has versions X,Y,Z. A table can be constructed based on the knowledge of the systems. MS P Situation ----------- ----------- --------------------- Case 1) X,Y X,Y At Same Level Case 2) X,Y,Z X,Y Printer older than MS Case 3) X,Y X,Y,Z MS Older than Printer Case 4) X,Y Z MS Older than Printer Case 5) Z X,Y Printer Older than MS So, let's analyze the requirements for each case. Case 1,2,3) unambiguity is sufficient Case 4,5) unambiguity is insufficient So, Case 4 & 5 are the only time that we would need the other information advocated by Tom Hastings, i.e. (Case 4) the Management station would like to know that there is a chance that interpreter Z may be OK for job Y (or X). This situation only arises because P is not fully disclosing it's capabilities. In Case 5, we are given a job Z that claims that it uses the new file format Z. However, it is likely that it may work on X or Y, since Z is an improved version from Y. (Case 4) I think this is an outlier problem and should not govern the decision. It is reasonable to ask P to disclose its capabilities. (Case 5) I don't mind if the request fails due to this mismatch. If the user wants completion, he should select a supported format. I take this position with full knowledge that the file format MAY work. The override should be a user-controlled issue. Therefore, I suggest that your conclusion is in fact still a good one and that we should consider unambiguity sufficient. -Raymond At 08:26 AM 4/1/96 M, Binnur Al-Kazily wrote: > >>So, with all that said, let me restate the question using this new point >>of view: >> >> If the printer supports say PostScript-I and PostScript-II "Control >>Protocols", why do we need to make a distinction if these protocols are >>handled by the same code and share much of the same data (i.e. in terms >>of fonts, etc.)? >> >>If there is no real justification to this question, then you would not >>need the new object/attribute that you are suggesting, Tom. > >Raymond, > >If this is the case, you are indicating that prtInterpreterLangLevel is >satisfactory, as long as it is not ambiguous. Is this conclusion >correct?? > > --- >Binnur Al-Kazily Hewlett-Packard Company Integrated Network Solutions >binnur@boi.hp.com (208)396-6372 KB7YWD DoD #2010 > > > ---------- > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ FYI: We may be voting on the new version of MFPI-1 at this meeting. -Raymond >Return-Path: >Date: Fri, 22 Mar 1996 18:04:16 +0000 >From: surban@attmail.com (Steve Urban) >Subject: TR-29 meeting notice >To: tr29-list@mirage.nsc.com >X-UIDL: 827538812.000 > > March 22, 1996 > >ORGANIZATION: TIA TR-29 Facsimile Systems & Equipment > TR-29.1 Facsimile and File Transfer Protocols > TR-29.2 Facsimile Programmable Interfaces > >CHAIR: Stephen Urban > TEL: (215) 657-5270 > FAX: (215) 657-5273 > EMAIL: surban@attmail.com > >DATE: May 13-16, 1996 > >TIME: 9:00 AM > >Meeting Location:Holiday Inn at Tinton Falls $72 +6%tax, includes full >breakfast > 700 Hope Road > Tinton Falls, NJ 07724 > Voice (800) 2JERSEY > (908) 544-9300 > FAX (908) 544-0570 > > Please ask for TR-29 meeting! (cutoff date - April 18, 1996) > >Directions from Newark airport: > >Take NJ Turnpike south to Garden State Parkway exit (11). >Take Garden State Parkway South to Exit 105. >The Holiday Inn is on your right after you exit the toll gate. > >Total travel time is about 45 minutes. > >Airport limo service is available from Olympic Limo. > >Reminder: Bring an adequate number (30 copies) of your >contributions/documents. Also bring a soft copy of contributions - the >preferred format is WORD 2.0, but any popular format is acceptable. Please >leave all viruses at home! > >Please check and sign this form and return to the Chair. >************************************************************* >Stephen J. Urban TR-29 Facsimile Systems >Delta Information Systems, Inc. May 13-16, 1996 >300 Welsh Road Ste 120 Holiday Inn at Tinton Falls >Horsham, PA 19044 Tinton Falls, NJ 07724 > >I will _____ ______________________ > attend the meeting Name >I will not _____ ______________________ > Company > > FYI: We may be voting on the new version of MFPI-1 at this meeting. -Raymond >Return-Path: >Date: Fri, 22 Mar 1996 18:04:16 +0000 >From: surban@attmail.com (Steve Urban) >Subject: TR-29 meeting notice >To: tr29-list@mirage.nsc.com >X-UIDL: 827538812.000 > > March 22, 1996 > >ORGANIZATION: TIA TR-29 Facsimile Systems & Equipment > TR-29.1 Facsimile and File Transfer Protocols > TR-29.2 Facsimile Programmable Interfaces > >CHAIR: Stephen Urban > TEL: (215) 657-5270 > FAX: (215) 657-5273 > EMAIL: surban@attmail.com > >DATE: May 13-16, 1996 > >TIME: 9:00 AM > >Meeting Location:Holiday Inn at Tinton Falls $72 +6%tax, includes full >breakfast > 700 Hope Road > Tinton Falls, NJ 07724 > Voice (800) 2JERSEY > (908) 544-9300 > FAX (908) 544-0570 > > Please ask for TR-29 meeting! (cutoff date - April 18, 1996) > >Directions from Newark airport: > >Take NJ Turnpike south to Garden State Parkway exit (11). >Take Garden State Parkway South to Exit 105. >The Holiday Inn is on your right after you exit the toll gate. > >Total travel time is about 45 minutes. > >Airport limo service is available from Olympic Limo. > >Reminder: Bring an adequate number (30 copies) of your >contributions/documents. Also bring a soft copy of contributions - the >preferred format is WORD 2.0, but any popular format is acceptable. Please >leave all viruses at home! > >Please check and sign this form and return to the Chair. >************************************************************* >Stephen J. Urban TR-29 Facsimile Systems >Delta Information Systems, Inc. May 13-16, 1996 >300 Welsh Road Ste 120 Holiday Inn at Tinton Falls >Horsham, PA 19044 Tinton Falls, NJ 07724 > >I will _____ ______________________ > attend the meeting Name >I will not _____ ______________________ > Company > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Just got this . . thought you should be aware. Al ______________________________ Forward Header __________________________________ Subject: ***Virus Alert*** Author: Tom_Tomkins@torho.xc.xerox.com at beluga-mail Date: 4/1/96 11:27 AM From: Ismail,Shamim To: ^5650 Yonge St@torho.XC Cc: Campbell,Ian; Dial,George; Ferguson,Ian; Jansson,Erik; Kannemann,Tom; MacDonald,Neil; MacKinnon,Ian; Major,Bill; Muhar,John; Paul Levesque@mtl.xc; Power,Tony; Robinson,Patrick; Thornes,Ted; Vucenovic,Zlatan; Yee,Jeff Subject: ***Virus Alert*** Date: Friday, March 29, 1996 5:14PM Priority: High As confirmed by Microsoft security: A new trojan horse virus has emerged on the internet with the name PKZIP300.ZIP, so named as to give the impression that this file is a new version of the PKZIP software used to ZIP (compress) files. Do not download this file under any circumstances! If you install or expand this file, the virus will wipe your hard disk and affect modems at 14.4 and higher. This is an extremely destructive virus and there is not yet a way of cleaning up this one. Repeat: Do not download any file with the name PKZIP300 regardless of the extension. IM/EDS Return-Path: Received: from xc-ngm-smtp.xc.xerox.com ([13.226.80.223]) by alpha.xerox.com with SMTP id <17831(10)>; Mon, 1 Apr 1996 09:20:20 PST X-Nvlenv-01Date-Transferred: 1-Apr-1996 12:32:56 -0500; at xc-ngm-smtp.xc X-Nvlenv-01Date-Posted: 01-Apr-1996 12:24:34 -0500; at XC-TOR-HO-MS2.XC Date: Mon, 1 Apr 1996 10:19:23 PST From: Tom_Tomkins@torho.xc.xerox.com To: <@[13.1.64.93]:Al_Harford@beluga.adoc.xerox.com> Subject: FW: ***Virus Alert*** And TCO on PC Disk for 735 Message-Id: <"C50E6031816A2E79@XC-TOR-HO-MS2.XC"@-SMF-> Shazia: Please find attached a MS/Word electronic version of the Project Initiation Notification System (PINS) Form requesting a project number to revise the IS-650 standard. We are expecting to have a revised specification ready for a committee decision by the next TR-29.2 meeting in May '96. In the meantime I will inquire if our intent is to: a) generate a new revision of the Interim Standard (i.e. IS-650-A), in which case, as you clarified, we must allow TIA to distribute the specification and allow a 30-day period for the TR-29.2 membership to vote; or if instead, b) the intention is to revise it and forward it for balloting as an ANSI standard; in this case, the TR-29.2 committee in May, with a quorum, if so desired, could vote to skip the Committee Letter Ballot and submit the proposal for an ANSI industry ballot. Feel free to correct me, if I misunderstood, Thanks, Vivian Cancio,Xerox Corp. Tel.(415) 813-7591 TR-29.2 Chair The following is an attached File item from cc:Mail. It contains information that had to be encoded to ensure successful transmission through various mail systems. To decode the file use the UUDECODE program. --------------------------------- Cut Here --------------------------------- Attachment Converted: Z:\MAIL\ATTACH\pin.doc Are you working on VxD development, especially COM drivers or IEEE-1284 drivers? Please check out the VCOMM mailing list. Information on how to subscribe to the list can be found in our web site, http://www.mfpa.org. CAUTION: Very detailed, very technical, very good! -Raymond MFPA Members/Raymond: I propose that we start discussing the following issues in preparation for the submission of the IS-650 as an ANSI standard and as part of the promotion at the IOC'96 conference in October. For example: 1) Since to date Microsoft has been unwilling to support a Plug and Play for single cable solution in multi-functional peripheral (MFPs) devices, and 2) therefore, given that the peripheral vendors have to include the host software necessary to drive the single cable MFPs (i.e. the resource manager, the link layer/packet protocol and device drivers) which is the extent of the IS-650 ... then ... How do we evaluate the value to vendors of complying with the standards? What value do you see for your own implementation? I would like to solicit and exchange ideas on this subject. Vivian Cancio Xerox Corp. (415) 813-7591 DN:MFPA-96-017 MFPA 1996 MEMBER SURVEY ----------------------- Purpose: HELP CHART THE COURSE OF THE MFPA! This survey is intended to provide new direction and/or validate the current direction of the MFPA working group(s), and the attention that we give to established standards groups that are not part of the MFPA. It is understood that it is inconvenient or impossible for all member companies to attend quarterly and working group meetings that are held more often. Therefore, as a member of MFPA, please complete the following questionaire. We will then summarize the results. Your responses are strictly confidential and your company identity will not be revealed with the results of this questionaire. TimeFrame: Please consider the questions carefully and respond by Friday, 4/26/1996. -----> DUE FRIDAY, 4/26/1996 <----- Please return the questionaire promptly so that we may compile the results for the upcoming meeting 5/1-2/1996. Questionaire Method: Many of the questions below are qualitative in nature. The following scale will be used for these questions: 0 - I don't know the answer or can't rate this 1 - Poor, Way too little, Needs much improvement 2 - Fair, Slightly too little, Needs some improvement 3 - Good, About right 4 - Extra, Slightly too much, Slight reduction in Costs here 5 - Excessive, Way too much, Major reduction in Costs here 1 - TECHNICAL ============= On what should the MFPA be spending time and energy? Please indicate your interest level in each of the following technical initiatives. Use 1-5, where 1 is the highest interest, and 5 is lowest interest. 1-1) [ ] Complete MFPI-1 IS-650 as an industry standard. 1-2) [ ] Work on MFPI-2 for Fax 1-3) [ ] Work on MFPI-2 for Printing 1-4) [ ] Work on MFPI-2 for Scanning 1-5) [ ] Work on MFPI-3 1-6) [ ] Work on MFPI-4 1-7) [ ] Map MFPI-1 to SCSI 1-8) [ ] Map MFPI-1 to HP-MLC and IEEE-1284.4 1-9) [ ] Map MFPI-1 to IEEE-1394 1-10) [ ] Map MFPI-1 to USB 1-11) [ ] Transportable Document Format (TDF) and InterDomain Job Submission 1-12) [ ] Improved T.30 Protocol (Integrated with Internet) 1-13) [ ] Troika API 1-14) [ ] MFP Levels of Service and graphic designation 1-15) [ ] MFP MIB 1-16) [ ] Scanner MIB 1-17) [ ] Internal MFP interconnect standards (scanner, printer, etc.) 1-18) [ ] Harmonization with Novell NDPS and NEST 1-19) [ ] CORBA and OLE integration of services in MFP. 1-20) [ ] Fax "routing" issues 1-21) [ ] Fax Extended Negotiations Protocols (ENPs) 1-22) [ ] IS-101 related voice-modem (answering machine) stds 1-23) [ ] Simultaneous voice/data (SVD) technologies 1-24) [ ] Simultaneous voice/fax technologies 1-25) [ ] Facsimile security 1-26) [ ] MFP Operator Console standards 1-27) [ ] Phonebooks standards (Bentograms, etc) 1-28) [ ] Test Suites for MFPI, various levels 1-29) [ ] Interoperability standards for MFPI 1-30) [ ] Generation of standard VxD and sample code for MFPI-1 1-31) [ ] High-Speed facsimile 1-32) [ ] Quality conformance standards for MFPs 1-33) [ ] Enhancement of T.611 Fax API for MFPs 1-34) [ ] Enhancement of DPA for MFPs 1-35) [ ] Generation of Class-3 fax standard 1-36) [ ] BFT enhancement 1-37) [ ] BFT interoperability 1-38) [ ] Remote rendering of printed documents on MFPs, but not TDF. 1-39) [ ] Harmonization with Adobe PDF and other initiatives 1-40) [ ] TIA TR29.1, Facsimile Protocols (improved PSTN protocols, BFT) 1-41) [ ] TIA TR29.2, DTE/DCE protocols (EX: MFPI, Class1, Class2, etc.) 1-42) [ ] TIA TR30 (Data Modem Standards Committees), Generally 1-43) [ ] IEEE-1284.1, TIPSI - Transport Independent Printer Systems Interface 1-44) [ ] IEEE-1284.2, IEEE-1284 testing 1-45) [ ] IEEE-1284.3, Daisy-chain and mux enhancements for IEEE-1284 1-46) [ ] IEEE-1284.4, Standardization of HP-MLC protocol 1-47) [ ] PWG: Printer Working Group, SNMP management of printers 1-48) [ ] DMTF, Desktop Management Task Force 1-49) [ ] Salutation Consortium 1-50) [ ] Electronic Mail Association (EMA) 1-51) [ ] AIIM, Generally 1-52) [ ] AIIM, MS-53 committee standardizing compressed image formats 1-53) [ ] AIIM, MS-64 committee standardizing ISIS scanner interface 1-54) [ ] TWAIN scanner API 1-55) [ ] IETF, Internet Engineering Task Force 1-56) [ ] ICTF, Integrated Communication Architecture 1-57) [ ] IRDA, Infrared Data Assocation 1-58) [ ] USB, Universal Serial Bus 1-59) [ ] IEEE-1394 Trade Association and "FireWire" involvement 1-60) [ ] X-3 SCSI Standards committees 1-61) [ ] CORBA: Common Object Request Broker Architecture 1-62) [ ] NetWare NDPS Architecture 1-63) [ ] NetWare NEST: NetWare Embedded Systems Technology 1-64) [ ] Wordcraft Computer Fax Protocol (CFP) 1-65) [ ] Versit Computer Telephony and Personal Data Interchange 1-66) [ ] ISO-10175 Document Printing Architecture 1-67) [ ] Other: 1-68) [ ] Other: 1-69) Comments and suggestions on Techinical Initiatives: 2 - ADMINISTRATION ================== 2-1) [ ] Rate the overall amount of service provided to members (0-5). 2-2) [ ] Rate the effectiveness and quality of quarterly meetings (0-5). 2-3) [ ] Rate the effectiveness and quality of working group meetings (0-5). 2-4) Please provide your first choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-5) Please provide your second choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-6) [ ] Rate the meeting geographical locations selected to date. 2-7) [ ] Rate the meeting site, rooms, costs, etc. 2-8) [ ] Would you be interested in sponsoring an MFPA meeting in your area? (Y/N) 2-9) [ ] Would you support meeting charges for the attendees if the meeting is not sponsored? (perhaps $25/day) (Y/N) 2-10) [ ] Rate the membership dues for members (0-5) 2-11) [ ] Rate your involvement and participation with the MFPA NOW (0-5) 2-12) [ ] Rate your future involvement and participation with the MFPA (0-5) 2-13) Comments and Suggestions on Administration topics: 2-14) What would allow you to attend more meetings? 3 - MARKETING ============= Web Site -------- 3-1) [ ] Rate the Web Site, in general. 3-2) [ ] Should draft documents of the MFPA be in a private area of the web site? (Y/N) 3-3) Suggestions for additions to the MFPA Web Site: Tradeshows ---------- 3-4) [ ] Rate the exposure of MFPA at the COMDEX tradeshow (0-5) 3-5) [ ] Rate the exposure of MFPA at the BTA tradeshow (0-5) 3-6) Suggestions for exposure and participation at tradeshows: General ------- 3-7) Suggestions for general marketing and exposure of the MFPA: Are you working on VxD development, especially COM drivers or IEEE-1284 drivers? Please check out the VCOMM mailing list. Information on how to subscribe to the list can be found in our web site, http://www.mfpa.org. CAUTION: Very detailed, very technical, very good! -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ DN:MFPA-96-017 MFPA 1996 MEMBER SURVEY ----------------------- Purpose: HELP CHART THE COURSE OF THE MFPA! This survey is intended to provide new direction and/or validate the current direction of the MFPA working group(s), and the attention that we give to established standards groups that are not part of the MFPA. It is understood that it is inconvenient or impossible for all member companies to attend quarterly and working group meetings that are held more often. Therefore, as a member of MFPA, please complete the following questionaire. We will then summarize the results. Your responses are strictly confidential and your company identity will not be revealed with the results of this questionaire. TimeFrame: Please consider the questions carefully and respond by Friday, 4/26/1996. -----> DUE FRIDAY, 4/26/1996 <----- Please return the questionaire promptly so that we may compile the results for the upcoming meeting 5/1-2/1996. Questionaire Method: Many of the questions below are qualitative in nature. The following scale will be used for these questions: 0 - I don't know the answer or can't rate this 1 - Poor, Way too little, Needs much improvement 2 - Fair, Slightly too little, Needs some improvement 3 - Good, About right 4 - Extra, Slightly too much, Slight reduction in Costs here 5 - Excessive, Way too much, Major reduction in Costs here 1 - TECHNICAL ============= On what should the MFPA be spending time and energy? Please indicate your interest level in each of the following technical initiatives. Use 1-5, where 1 is the highest interest, and 5 is lowest interest. 1-1) [ ] Complete MFPI-1 IS-650 as an industry standard. 1-2) [ ] Work on MFPI-2 for Fax 1-3) [ ] Work on MFPI-2 for Printing 1-4) [ ] Work on MFPI-2 for Scanning 1-5) [ ] Work on MFPI-3 1-6) [ ] Work on MFPI-4 1-7) [ ] Map MFPI-1 to SCSI 1-8) [ ] Map MFPI-1 to HP-MLC and IEEE-1284.4 1-9) [ ] Map MFPI-1 to IEEE-1394 1-10) [ ] Map MFPI-1 to USB 1-11) [ ] Transportable Document Format (TDF) and InterDomain Job Submission 1-12) [ ] Improved T.30 Protocol (Integrated with Internet) 1-13) [ ] Troika API 1-14) [ ] MFP Levels of Service and graphic designation 1-15) [ ] MFP MIB 1-16) [ ] Scanner MIB 1-17) [ ] Internal MFP interconnect standards (scanner, printer, etc.) 1-18) [ ] Harmonization with Novell NDPS and NEST 1-19) [ ] CORBA and OLE integration of services in MFP. 1-20) [ ] Fax "routing" issues 1-21) [ ] Fax Extended Negotiations Protocols (ENPs) 1-22) [ ] IS-101 related voice-modem (answering machine) stds 1-23) [ ] Simultaneous voice/data (SVD) technologies 1-24) [ ] Simultaneous voice/fax technologies 1-25) [ ] Facsimile security 1-26) [ ] MFP Operator Console standards 1-27) [ ] Phonebooks standards (Bentograms, etc) 1-28) [ ] Test Suites for MFPI, various levels 1-29) [ ] Interoperability standards for MFPI 1-30) [ ] Generation of standard VxD and sample code for MFPI-1 1-31) [ ] High-Speed facsimile 1-32) [ ] Quality conformance standards for MFPs 1-33) [ ] Enhancement of T.611 Fax API for MFPs 1-34) [ ] Enhancement of DPA for MFPs 1-35) [ ] Generation of Class-3 fax standard 1-36) [ ] BFT enhancement 1-37) [ ] BFT interoperability 1-38) [ ] Remote rendering of printed documents on MFPs, but not TDF. 1-39) [ ] Harmonization with Adobe PDF and other initiatives 1-40) [ ] TIA TR29.1, Facsimile Protocols (improved PSTN protocols, BFT) 1-41) [ ] TIA TR29.2, DTE/DCE protocols (EX: MFPI, Class1, Class2, etc.) 1-42) [ ] TIA TR30 (Data Modem Standards Committees), Generally 1-43) [ ] IEEE-1284.1, TIPSI - Transport Independent Printer Systems Interface 1-44) [ ] IEEE-1284.2, IEEE-1284 testing 1-45) [ ] IEEE-1284.3, Daisy-chain and mux enhancements for IEEE-1284 1-46) [ ] IEEE-1284.4, Standardization of HP-MLC protocol 1-47) [ ] PWG: Printer Working Group, SNMP management of printers 1-48) [ ] DMTF, Desktop Management Task Force 1-49) [ ] Salutation Consortium 1-50) [ ] Electronic Mail Association (EMA) 1-51) [ ] AIIM, Generally 1-52) [ ] AIIM, MS-53 committee standardizing compressed image formats 1-53) [ ] AIIM, MS-64 committee standardizing ISIS scanner interface 1-54) [ ] TWAIN scanner API 1-55) [ ] IETF, Internet Engineering Task Force 1-56) [ ] ICTF, Integrated Communication Architecture 1-57) [ ] IRDA, Infrared Data Assocation 1-58) [ ] USB, Universal Serial Bus 1-59) [ ] IEEE-1394 Trade Association and "FireWire" involvement 1-60) [ ] X-3 SCSI Standards committees 1-61) [ ] CORBA: Common Object Request Broker Architecture 1-62) [ ] NetWare NDPS Architecture 1-63) [ ] NetWare NEST: NetWare Embedded Systems Technology 1-64) [ ] Wordcraft Computer Fax Protocol (CFP) 1-65) [ ] Versit Computer Telephony and Personal Data Interchange 1-66) [ ] ISO-10175 Document Printing Architecture 1-67) [ ] Other: 1-68) [ ] Other: 1-69) Comments and suggestions on Techinical Initiatives: 2 - ADMINISTRATION ================== 2-1) [ ] Rate the overall amount of service provided to members (0-5). 2-2) [ ] Rate the effectiveness and quality of quarterly meetings (0-5). 2-3) [ ] Rate the effectiveness and quality of working group meetings (0-5). 2-4) Please provide your first choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-5) Please provide your second choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-6) [ ] Rate the meeting geographical locations selected to date. 2-7) [ ] Rate the meeting site, rooms, costs, etc. 2-8) [ ] Would you be interested in sponsoring an MFPA meeting in your area? (Y/N) 2-9) [ ] Would you support meeting charges for the attendees if the meeting is not sponsored? (perhaps $25/day) (Y/N) 2-10) [ ] Rate the membership dues for members (0-5) 2-11) [ ] Rate your involvement and participation with the MFPA NOW (0-5) 2-12) [ ] Rate your future involvement and participation with the MFPA (0-5) 2-13) Comments and Suggestions on Administration topics: 2-14) What would allow you to attend more meetings? 3 - MARKETING ============= Web Site -------- 3-1) [ ] Rate the Web Site, in general. 3-2) [ ] Should draft documents of the MFPA be in a private area of the web site? (Y/N) 3-3) Suggestions for additions to the MFPA Web Site: Tradeshows ---------- 3-4) [ ] Rate the exposure of MFPA at the COMDEX tradeshow (0-5) 3-5) [ ] Rate the exposure of MFPA at the BTA tradeshow (0-5) 3-6) Suggestions for exposure and participation at tradeshows: General ------- 3-7) Suggestions for general marketing and exposure of the MFPA: /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Vivian I like it when talk suddenly turns to implementation! There is a bit of a chicken or the egg situation here. Do we have any manufacturers who are committed to producing IS-650 MFP devices in the short or medium term? If so it becomes worth while software developers tooling up to support them. I'll declare an interest here: Wordcraft would like to support such devices from our stand-alone and network software packages for printing, scanning, fax, voice and data. In my terms we are interested in developing drivers for such devices. (I don't want to get into a long academic debate about what a "driver" is - I know what I mean - it's what makes it work from our applications - that's good enough for me.) I noted Ray's comment about VxDs and I entirely agree that this is a very important area - we have VxDs for IEEE 1284 for example. We support applications that operate on serial as well as IEEE 1284 (via re-direction etc.) and we give the broadest possible coverage of Microsoft's ever changing and ever worsening "operating systems". So far we are into W 3.1, W 3.11, W '95 and NT 4.something. (I sometimes get a bit bogged down with what is a "real" OS release and what is a YAB - "Yet Another Beta.") As you can imagine, we have most of this already in place to support existing CFP machines and we have some hefty VxD, redirection, client/server, scheduling and resource handling stuff well under way (all for release this summer). We have also been doing a lot of work to provide true TWAIN compatibility for MFPs without manufacturers having to do anything special. Couple this with colour printing and scanning and life is interesting at the moment! So - who's implementing IS-650 in real MFP hardware then? Any takers? If so, please contact me 'cus we'd like to support you! Cheers Mike >1) Since to date Microsoft has been unwilling to support a Plug and Play >for single cable solution in multi-functional peripheral (MFPs) devices, >and >2) therefore, given that the peripheral vendors have to include the >host software necessary to drive the single cable MFPs (i.e. the resource >manager, the link layer/packet protocol and device drivers) which is the >extent of the IS-650 ... >then ... >How do we evaluate the value to vendors of complying with the standards? >What value do you see for your own implementation? ****************************************************************** * Mike Lake mlake@wcraft.win-uk.net * * Managing Director * * Wordcraft International Limited Voice: +44-1332-371428 * * Kelmscot House Fax: +44-1332-295525 * * Vernon Street BBS: +44-1332-380034 * * Derby DE1 1FR * * United Kingdom * * * * Comms software products: LaserFAX/HydraFAX/CFP/ReSponD/Sopwith * ****************************************************************** I have placed two documents on the mfpa ftp server, as follows: ftp://ftp.cts.com/pub/MFPA/is650_53.doz ftp://ftp.cts.com/pub/MFPA/650chg53.doc "is650_53.doz" is a Winword 6.0 document, pkzipped (pkzip 2.04g), and password protected. If you are an MFPA member, you should be issued a password on 4/10/1996 to access this document. If you want to review it and don't have the password, please contact the mfpa office, and we will issue it to MFPA members or TIA TR29.2 committee members. Use the "-s" switch in the PKUNZIP command to get it to use the password, like this: PKUNZIP -s is650_52.doz It will prompt you for the password. The other file is not password protected, but it is winword 6.0. It describes the changes to the document. ----> PLEASE STUDY THIS DOCUMENT. <---- The major change is the addition of the SCSI channel, and moving the Multifunction Packet Protocol (MFPP) from section 8 to an Annex. This is a moving target, and I will have a new version available at the upcoming 5/1-2/1996 meeting. However, please review this version and have any questions or desired changes at that meeting. Enjoy! -Raymond I have placed two documents on the mfpa ftp server, as follows: ftp://ftp.cts.com/pub/MFPA/is650_53.doz ftp://ftp.cts.com/pub/MFPA/650chg53.doc "is650_53.doz" is a Winword 6.0 document, pkzipped (pkzip 2.04g), and password protected. If you are an MFPA member, you should be issued a password on 4/10/1996 to access this document. If you want to review it and don't have the password, please contact the mfpa office, and we will issue it to MFPA members or TIA TR29.2 committee members. Use the "-s" switch in the PKUNZIP command to get it to use the password, like this: PKUNZIP -s is650_52.doz It will prompt you for the password. The other file is not password protected, but it is winword 6.0. It describes the changes to the document. ----> PLEASE STUDY THIS DOCUMENT. <---- The major change is the addition of the SCSI channel, and moving the Multifunction Packet Protocol (MFPP) from section 8 to an Annex. This is a moving target, and I will have a new version available at the upcoming 5/1-2/1996 meeting. However, please review this version and have any questions or desired changes at that meeting. Enjoy! -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ I have placed the new version of IS-650 on the ftp site as: ftp://ftp.cts.com/pub/MFPA/is650_53.doz You will need a password to access this document. This is required by TIA and more recently by the decision of the MFPA Executive council. It is our intention to make this more transparent to you, however, in the interim, we are using the encryption capabilities of PKZIP. Use the following to access: PKUNZIP -slambda is650_53.doz The result is is650_53.doc, a winword 6.0 file. -Raymond I have placed the new version of IS-650 on the ftp site as: ftp://ftp.cts.com/pub/MFPA/is650_53.doz You will need a password to access this document. This is required by TIA and more recently by the decision of the MFPA Executive council. It is our intention to make this more transparent to you, however, in the interim, we are using the encryption capabilities of PKZIP. Use the following to access: PKUNZIP -slambda is650_53.doz The result is is650_53.doc, a winword 6.0 file. -Raymond To MFPA Members and Propective Members: Please join me in welcoming Wind River Systems to the MFPA, as of March, 1996. Their primary contact will be David Larrimore. Here is a brief description of Wind River Systems: > >Wind River Systems, Inc. develops, markets and supports software for >developing real-time embedded applications in the office automation, >computer peripherals, networking, telecommunications, medical, automotive, >industrial, aerospace and multimedia industries. It's award winning >Tornado development environment and scalable VxWorks® real-time operating >system have over 4,000 design wins worldwide including monochrome and color >office automation products ranging from low-end ink jet printers, SOHO MFPs >and high-end networked copier-based products. Wind River's products enable >their customers to enjoy rapid time-to-market and standardize their designs >across products. Incorporated in 1983, Wind River is headquartered in >Alameda, California with operations in the UK, France, Germany, Sweden and >Japan and representation worldwide. Wind River Systems 1010 Atlantic Ave Alameda, CA 94501 510-748-4100 tel 510 814 2010 fax http://www.wrs.com Regards, Kathie Cuban Director of Member Services * From the MFPA Reflector, posted by: * Kathleen R. Cuban - MFPA This is a monthly posting to the MFPA Reflector. If you receive this message, it means that either you are subscribed to the MFPA Reflector email list or you are on a re-reflector (probably set up and maintained by someone in your company). The MFPA Reflector is provided and maintained by MFPA (Multifunction Peripheral Association). This reflector exists to discuss technical issues and to disseminate MFPA standards-related information (minutes, meeting notices, etc.). The MFPA Reflector is not intended to carry commercial traffic. People who post advertisements, job offers, etc. will be removed from the reflector. The MFPA Reflector is managed and maintained manually. To post to the MFPA Reflector, send your message to: MFPA@mfpa.org To subscribe or unsubscribe, send an email message to: mfpa-request@mfpa.org Be sure to include in your message your full name and email address. If you wish to be added to our hard mail list also include your physical address and phone/fax numbers. If you have any problems with the MPFA Reflector, please send a message to: mfpa-request@mfpa.org Additional information sources about MFPA: WWW: www.MFPA.org TO: MFPA Members and Prospective Members SUBJECT: New Membership Structure of MFPA - June 1st, 1996 Hello all members and prospective members! This memo is to announce the new 4-tier membership structure for MFPA, which will go into effect June 1st. This new structure was designed to allow individual and small business participation, without placing an unfair burden on the medium to larger companies. For all current members who will be renewing soon, or for all of you who have been contemplating joining, this is your last chance to renew or join before the new dues structure goes into effect! Dues payments received by April 30th, will be credited under the current dues structure. So take advantage of this before its too late. Even if your membership will not lapse until later this year, we are contacting you now to encourage early payment of your dues to take advantage of the current rates. Attached is a complete explanation of each membership level along with a description of the benefits and restrictions. Please review it and let us know if you have any questions or comments. We're expecting 1996 to be a great year with expanded services and an even better conference this year with IOC'96. You won't want to be left out! Yours truly, Kathleen R. Cuban Director of Member Services MFPA MEMBERSHIP STRUCTURE ------------------------- Company Size/ Annual Revenue Type of Member Dues ---------------------------- -------------- ---- $0 - $1M Individual $300 $1M+ - $50M Small Business $2000 $50M + - $500M Medium Business $5000 >$500M Large Business $8000 Benefits and Restrictions: ------------------------- Individual Membership No Vote No Advertising on web site or PR materials. May not be Executive Council member Full Document Access. Discounts on conferences, etc. for one person. One person may attend meetings. No distribution of hardcopy materials. Small Business 1 Vote Advertising on Web site. May be Executive Council member Document Access Discounts for any number of people to conferences, etc. Limited to 2 attendees per General Meeting. Single distribution point for hardcopy materials. Medium Business 1 Vote Advertising on Web site. May be Executive Council member Document Access Discounts for any number of people to conferences, etc. Any number of attendees per general meeting. Up to 3 distribution points for hardcopy materials. Large Business 1 Vote Advertising on Web site. May be Executive Council member Document Access Discounts for any number of people to conferences, etc. Any number of attendees per general meeting. Up to 5 distribution points for hardcopy materials. To MFPA Members and Propective Members: Please join me in welcoming Wind River Systems to the MFPA, as of March, 1996. Their primary contact will be David Larrimore. Here is a brief description of Wind River Systems: > >Wind River Systems, Inc. develops, markets and supports software for >developing real-time embedded applications in the office automation, >computer peripherals, networking, telecommunications, medical, automotive, >industrial, aerospace and multimedia industries. It's award winning >Tornado development environment and scalable VxWorks® real-time operating >system have over 4,000 design wins worldwide including monochrome and color >office automation products ranging from low-end ink jet printers, SOHO MFPs >and high-end networked copier-based products. Wind River's products enable >their customers to enjoy rapid time-to-market and standardize their designs >across products. Incorporated in 1983, Wind River is headquartered in >Alameda, California with operations in the UK, France, Germany, Sweden and >Japan and representation worldwide. Wind River Systems 1010 Atlantic Ave Alameda, CA 94501 510-748-4100 tel 510 814 2010 fax http://www.wrs.com Regards, Kathie Cuban Director of Member Services ************************************************************************** Kathleen R. Cuban Phone: 800-603-MFPA or Director of Member Services 619-447-1127 MFPA Fax: 619-447-6872 1010 Old Chase Ave., Ste B EMail: MFPA-request@cognysis.com El Cajon, CA 92020 ************************************************************************** * From the MFPA Reflector, posted by: * Kathleen R. Cuban - MFPA This is a monthly posting to the MFPA Reflector. If you receive this message, it means that either you are subscribed to the MFPA Reflector email list or you are on a re-reflector (probably set up and maintained by someone in your company). The MFPA Reflector is provided and maintained by MFPA (Multifunction Peripheral Association). This reflector exists to discuss technical issues and to disseminate MFPA standards-related information (minutes, meeting notices, etc.). The MFPA Reflector is not intended to carry commercial traffic. People who post advertisements, job offers, etc. will be removed from the reflector. The MFPA Reflector is managed and maintained manually. To post to the MFPA Reflector, send your message to: MFPA@mfpa.org To subscribe or unsubscribe, send an email message to: mfpa-request@mfpa.org Be sure to include in your message your full name and email address. If you wish to be added to our hard mail list also include your physical address and phone/fax numbers. If you have any problems with the MPFA Reflector, please send a message to: mfpa-request@mfpa.org Additional information sources about MFPA: WWW: www.MFPA.org ************************************************************************** Kathleen R. Cuban Phone: 800-603-MFPA or Director of Member Services 619-447-1127 MFPA Fax: 619-447-6872 1010 Old Chase Ave., Ste B EMail: MFPA-request@cognysis.com El Cajon, CA 92020 ************************************************************************** TO: MFPA Members and Prospective Members SUBJECT: New Membership Structure of MFPA - June 1st, 1996 Hello all members and prospective members! This memo is to announce the new 4-tier membership structure for MFPA, which will go into effect June 1st. This new structure was designed to allow individual and small business participation, without placing an unfair burden on the medium to larger companies. For all current members who will be renewing soon, or for all of you who have been contemplating joining, this is your last chance to renew or join before the new dues structure goes into effect! Dues payments received by April 30th, will be credited under the current dues structure. So take advantage of this before its too late. Even if your membership will not lapse until later this year, we are contacting you now to encourage early payment of your dues to take advantage of the current rates. Attached is a complete explanation of each membership level along with a description of the benefits and restrictions. Please review it and let us know if you have any questions or comments. We're expecting 1996 to be a great year with expanded services and an even better conference this year with IOC'96. You won't want to be left out! Yours truly, Kathleen R. Cuban Director of Member Services MFPA MEMBERSHIP STRUCTURE ------------------------- Company Size/ Annual Revenue Type of Member Dues ---------------------------- -------------- ---- $0 - $1M Individual $300 $1M+ - $50M Small Business $2000 $50M + - $500M Medium Business $5000 >$500M Large Business $8000 Benefits and Restrictions: ------------------------- Individual Membership No Vote No Advertising on web site or PR materials. May not be Executive Council member Full Document Access. Discounts on conferences, etc. for one person. One person may attend meetings. No distribution of hardcopy materials. Small Business 1 Vote Advertising on Web site. May be Executive Council member Document Access Discounts for any number of people to conferences, etc. Limited to 2 attendees per General Meeting. Single distribution point for hardcopy materials. Medium Business 1 Vote Advertising on Web site. May be Executive Council member Document Access Discounts for any number of people to conferences, etc. Any number of attendees per general meeting. Up to 3 distribution points for hardcopy materials. Large Business 1 Vote Advertising on Web site. May be Executive Council member Document Access Discounts for any number of people to conferences, etc. Any number of attendees per general meeting. Up to 5 distribution points for hardcopy materials. ************************************************************************** Kathleen R. Cuban Phone: 800-603-MFPA or Director of Member Services 619-447-1127 MFPA Fax: 619-447-6872 1010 Old Chase Ave., Ste B EMail: MFPA-request@cognysis.com El Cajon, CA 92020 ************************************************************************** Raymond: I took some excerpts from your message: (a) "If we have these various manufacturers making peripherals with similar interfaces, then 1) MS will eventually support it (given also that LMI is dead), and/or 2) third party sources will see a good business situation where they can support a single standard and will therefore have a "unidriver" for MFP peripherals." (b) "If everyone does their own thing, then we will not be able to generate critical mass behind a given protocol. Nevertheless, you are right in that the standards area, host to peripheral, is somewhat 'weak' since you can provide both sides, and therefore do anything you want potentially." _______________________________________ I tend to agree with your comments ... but yet ... ... we don't want (b) because we don't want to provide both sides, but yet we might be forced to, because (a) hasn't happened yet. The 'economics' (or value) at the moment seems to be on the side of (b). What can we do to make (a) happen? What if the MFPA generates the "unidriver"? If the cost is less to its members than going the (b) route, there is incentive. Vivian ______________________________ Reply Separator _________________________________ Subject: Re: IS-650 (MFPI) and Plug and Play Author: raylutz@cognisys.com (Raymond Lutz) at beluga-mail Date: 4/6/96 12:49 PM Vivian: I have taken the liberty to change the subject line slightly. My response below. > For example: > 1) Since to date Microsoft has been unwilling to support a Plug and Play > for single cable solution in multi-functional peripheral (MFPs) > devices, and > 2) therefore, given that the peripheral vendors have to include the > host software necessary to drive the single cable MFPs (i.e. the > resource manager, the link layer/packet protocol and device drivers) > which is the extent of the IS-650 ... > then ... > > How do we evaluate the value to vendors of complying with the > standards? What value do you see for your own implementation? Microsoft is a major player. But, you assume that MS is the only source for drivers and host-based software to perform the interaction with the device. If this is false, then other driver vendors may supply software which can drive a number of devices. The Plug and Play mechanism is not reliant upon the specific support of MS for MFP devices on one cable. If this is true, then if they don't want to support the standards, then the individual manufacturers will have to supply their own. This is your assumption, and so let's go with it. If we have these various manufacturers making peripherals with similar interfaces, then 1) MS will eventually support it (given also that LMI is dead), and/or 2) third party sources will see a good business situation where they can support a single standard and will therefore have a "unidriver" for MFP peripherals. If everyone does their own thing, then we will not be able to generate critical mass behind a given protocol. There are other good things about IS-650 which are not evident in the limited scenario that you are looking at. If you get above the Low-end device, then IS-650 will have important purposes as well. I think this will be seen in the new draft (which should be out by Monday). Nevertheless, you are right in that the standards area, host to peripheral, is somewhat "weak" since you can provide both sides, and therefore do anything you want potentially. Recently, the MFPA started working on "Interdomain Job Submission", which is a stronger standards area because you can't control both sides in general. However, it is a large project, and many implementors want solutions for near-term problems. Also, the standardization of an API for use with the various levels of MFPI will help the third-party developers and apps folks. We are putting together a draft of this API now for review shortly, hopefully in the next week or so. I think it will be a bit premature to put this stuff into the IS-650 standard though. By the way, I will be distributing a survey of these sort of issues for the MFPA members to respond to, and we can then compile some results to give us a better idea of what everyone really thinks about this stuff. A first draft has been completed and reviewed. Again, I hope to have this done this weekend. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Raymond: I took some excerpts from your message: (a) "If we have these various manufacturers making peripherals with similar interfaces, then 1) MS will eventually support it (given also that LMI is dead), and/or 2) third party sources will see a good business situation where they can support a single standard and will therefore have a "unidriver" for MFP peripherals." (b) "If everyone does their own thing, then we will not be able to generate critical mass behind a given protocol. Nevertheless, you are right in that the standards area, host to peripheral, is somewhat 'weak' since you can provide both sides, and therefore do anything you want potentially." _______________________________________ I tend to agree with your comments ... but yet ... ... we don't want (b) because we don't want to provide both sides, but yet we might be forced to, because (a) hasn't happened yet. The 'economics' (or value) at the moment seems to be on the side of (b). What can we do to make (a) happen? What if the MFPA generates the "unidriver"? If the cost is less to its members than going the (b) route, there is incentive. Vivian ______________________________ Reply Separator _________________________________ Subject: Re: IS-650 (MFPI) and Plug and Play Author: raylutz@cognisys.com (Raymond Lutz) at beluga-mail Date: 4/6/96 12:49 PM Vivian: I have taken the liberty to change the subject line slightly. My response below. > For example: > 1) Since to date Microsoft has been unwilling to support a Plug and Play > for single cable solution in multi-functional peripheral (MFPs) > devices, and > 2) therefore, given that the peripheral vendors have to include the > host software necessary to drive the single cable MFPs (i.e. the > resource manager, the link layer/packet protocol and device drivers) > which is the extent of the IS-650 ... > then ... > > How do we evaluate the value to vendors of complying with the > standards? What value do you see for your own implementation? Microsoft is a major player. But, you assume that MS is the only source for drivers and host-based software to perform the interaction with the device. If this is false, then other driver vendors may supply software which can drive a number of devices. The Plug and Play mechanism is not reliant upon the specific support of MS for MFP devices on one cable. If this is true, then if they don't want to support the standards, then the individual manufacturers will have to supply their own. This is your assumption, and so let's go with it. If we have these various manufacturers making peripherals with similar interfaces, then 1) MS will eventually support it (given also that LMI is dead), and/or 2) third party sources will see a good business situation where they can support a single standard and will therefore have a "unidriver" for MFP peripherals. If everyone does their own thing, then we will not be able to generate critical mass behind a given protocol. There are other good things about IS-650 which are not evident in the limited scenario that you are looking at. If you get above the Low-end device, then IS-650 will have important purposes as well. I think this will be seen in the new draft (which should be out by Monday). Nevertheless, you are right in that the standards area, host to peripheral, is somewhat "weak" since you can provide both sides, and therefore do anything you want potentially. Recently, the MFPA started working on "Interdomain Job Submission", which is a stronger standards area because you can't control both sides in general. However, it is a large project, and many implementors want solutions for near-term problems. Also, the standardization of an API for use with the various levels of MFPI will help the third-party developers and apps folks. We are putting together a draft of this API now for review shortly, hopefully in the next week or so. I think it will be a bit premature to put this stuff into the IS-650 standard though. By the way, I will be distributing a survey of these sort of issues for the MFPA members to respond to, and we can then compile some results to give us a better idea of what everyone really thinks about this stuff. A first draft has been completed and reviewed. Again, I hope to have this done this weekend. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Vivian: I think an answer to your question is not trivial. Getting critical mass behind standards requires quite a number of supporting factors. However, I think the API that I am currently working on will be one of the contributing factors to pushing this forward, and getting support from MS or other third parties. It seems MS's pride has been bruised somewhat by the MAW project, and they are going to think a while so that they will fail again. I think I would do the same in their shoes. So, we probably shouldn't hold our breath over MS's involvement. I should have a first draft of the API done this week. -Raymond > Raymond: > > I took some excerpts from your message: > > (a) "If we have these various manufacturers making peripherals with > similar interfaces, then > 1) MS will eventually support it (given also that LMI is dead), > and/or > 2) third party sources will see a good business situation where > they can support a single standard and will therefore have a > "unidriver" for MFP peripherals." > > (b) "If everyone does their own thing, then we will not be able to > generate critical mass behind a given protocol. Nevertheless, you > are right in that the standards area, host to peripheral, is > somewhat 'weak' since you can provide both sides, and therefore > do anything you want potentially." > _______________________________________ > I tend to agree with your comments ... but yet ... > > ... we don't want (b) because we don't want to provide both sides, but > yet we might be forced to, because (a) hasn't happened yet. The > 'economics' (or value) at the moment seems to be on the side of (b). > > What can we do to make (a) happen? What if the MFPA generates the > "unidriver"? If the cost is less to its members than going the (b) > route, there is incentive. > > > Vivian > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Vivian: Just in case someone else is having the same problem as you, here is the solution to the "puzzle": In Netscape, select Options|Preferences|Helper-Applications. Select "NEW" and type for MIME type "application" and for the second box type "x-zip-compressed". Choose OK, and then assign "doz" as the extension and check the "ASK USER" checkbox. Then it should load it again or you may have to load it again. Then it should unzip ok. I tried it and it worked, so I think if I explained it right, it should work for you... Enjoy! -Raymond > Raymond: > I have downloaded the new IS650 Version 5.3 but in attempting to > pkunzip I get a message: "... Bad Table ... fails CRC". > The result is an empty .doc. > Can you enlighten me. > By the way, I'm using Netscape, when you try to download, it > doesn't behave in the normal way; normally, if it doesn't have a > viewer, it just asks you how you want to deal with the file and you > normally instruct to save it in your disk, etc. In this case, it > thinks it's ASCII and displays the "garbage" on the screen and > consequently, at that point I have no other choice than to choose Save > As ... from the File Menu. I'm afraid that in attempting (Netscape) to > display the file, it might have changed it and when it gets saved is > no longer the same exact file. > I don't seem to be able to select the file (for downloading) and > prevent it from getting the "garbage" displayed. > > Vivian > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPI-1 Version 5.3 Reviewers: There are a number of issues outstanding in IS-650. I have marked those with @@. One of the issues has to do with sending HINQ? statement to the host if there is no channel establised. I have this message from a reviewer: > There seems to be a contradiction in Page84 of MFPI-1 Version5.3. Or I > may be misunderstanding. > > In 11.3.2 the Scanner -> Host sequence, > There is a step that MFP sends STS ; & HINQ? 1; > to Host. And you will see the next line that Host send RSRV 30 2;. > That means scanner subsystem is sending "STS ;" to > Host before being reserved by Host. > > That is the point which seems to be a contraditicion to me. > > I would like to make this clear. > You make a good point about the use of HINQ?. There is a @@ by this section to indicate that this is a problem that has already been detected. I'm not sure what the best resolution is, but I am thinking that sending it to the resource manager may be the best course. (i.e. unsolicited messages which we want to send to the host would go by way of the resource manager channel if there is no subsystem channel established.) It would then be the job of the host resource manager to launch the appropriate application which would then reserve the subsystem. It would be good to have the other reviewers consider this point. It is certain that this example should be reworked. -Raymond Dear Mike Lake: Since you are the primary CFP advocate, I would like to formally request some help from you in the details to allow this language from within MFPI-1. I have added the text in the document, but we need to know several things: 1) What is the language specifier. Should we use: "WORDCRFT|CFP|3.7" I would like to keep the vendor name down to 8 characters to be compatible with the SCSI spec (Wordcraft is currently not in it). CFP is a good language name. What about the version? I just made up 3.7. Please supply a document reference for the references section. 2) We need to comment on the stuff in CFP that won't work when used with MFPI. I don't think there is too much of this, but there is some comments on the fact that we won't be using the CFP packet structure or IEEE-1284 details from the CFP specification. Mike: Thanks in advance for your help. -Raymond MFPI-1 Version 5.3 Reviewers: There are a number of issues outstanding in IS-650. I have marked those with @@. One of the issues has to do with sending HINQ? statement to the host if there is no channel establised. I have this message from a reviewer: > There seems to be a contradiction in Page84 of MFPI-1 Version5.3. Or I > may be misunderstanding. > > In 11.3.2 the Scanner -> Host sequence, > There is a step that MFP sends STS ; & HINQ? 1; > to Host. And you will see the next line that Host send RSRV 30 2;. > That means scanner subsystem is sending "STS ;" to > Host before being reserved by Host. > > That is the point which seems to be a contraditicion to me. > > I would like to make this clear. > You make a good point about the use of HINQ?. There is a @@ by this section to indicate that this is a problem that has already been detected. I'm not sure what the best resolution is, but I am thinking that sending it to the resource manager may be the best course. (i.e. unsolicited messages which we want to send to the host would go by way of the resource manager channel if there is no subsystem channel established.) It would then be the job of the host resource manager to launch the appropriate application which would then reserve the subsystem. It would be good to have the other reviewers consider this point. It is certain that this example should be reworked. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Dear Mike Lake: Since you are the primary CFP advocate, I would like to formally request some help from you in the details to allow this language from within MFPI-1. I have added the text in the document, but we need to know several things: 1) What is the language specifier. Should we use: "WORDCRFT|CFP|3.7" I would like to keep the vendor name down to 8 characters to be compatible with the SCSI spec (Wordcraft is currently not in it). CFP is a good language name. What about the version? I just made up 3.7. Please supply a document reference for the references section. 2) We need to comment on the stuff in CFP that won't work when used with MFPI. I don't think there is too much of this, but there is some comments on the fact that we won't be using the CFP packet structure or IEEE-1284 details from the CFP specification. Mike: Thanks in advance for your help. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Ray - what is the intended use of "owner" or "company" in your PDL naming scheme? Is it meant to distinguish between different vendor implementations (or emulations) of the originally defined language (ie clones)? Aside from the company part, your scheme seems to map quite well into the existing Printer MIB. Granted, we only register enums for the Family part (your PCL, PS etc.), but, looking at all your examples, the lang level strings appear to easily be made unambiguous. >So MFPI-1 will contain the following list of "standard" document description >language identifiers for printers in its Appendix C: > > HP|PCL|3 > HP|PCL|4 > HP|PCL|5 > HP|PCL|5E > ADOBE|PS|1 > ADOBE|PS|2 Ray - what is the intended use of "owner" or "company" in your PDL naming scheme? Is it meant to distinguish between different vendor implementations (or emulations) of the originally defined language (ie clones)? Aside from the company part, your scheme seems to map quite well into the existing Printer MIB. Granted, we only register enums for the Family part (your PCL, PS etc.), but, looking at all your examples, the lang level strings appear to easily be made unambiguous. >So MFPI-1 will contain the following list of "standard" document description >language identifiers for printers in its Appendix C: > > HP|PCL|3 > HP|PCL|4 > HP|PCL|5 > HP|PCL|5E > ADOBE|PS|1 > ADOBE|PS|2 Ray - what is the intended use of "owner" or "company" in your PDL naming scheme? Is it meant to distinguish between different vendor implementations (or emulations) of the originally defined language (ie clones)? Aside from the company part, your scheme seems to map quite well into the existing Printer MIB. Granted, we only register enums for the Family part (your PCL, PS etc.), but, looking at all your examples, the lang level strings appear to easily be made unambiguous. >So MFPI-1 will contain the following list of "standard" document description >language identifiers for printers in its Appendix C: > > HP|PCL|3 > HP|PCL|4 > HP|PCL|5 > HP|PCL|5E > ADOBE|PS|1 > ADOBE|PS|2 Is the PDL naming scheme describing the device, or is it describing the media that the device accepts? >So MFPI-1 will contain the following list of "standard" document description >language identifiers for printers in its Appendix C: In this phrasing, it seems that you're describing media types rather than devices, and that you might want to use application/postscript or some such. Larry Masinter Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333 Is the PDL naming scheme describing the device, or is it describing the media that the device accepts? >So MFPI-1 will contain the following list of "standard" document description >language identifiers for printers in its Appendix C: In this phrasing, it seems that you're describing media types rather than devices, and that you might want to use application/postscript or some such. Larry Masinter Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333 Is the PDL naming scheme describing the device, or is it describing the media that the device accepts? >So MFPI-1 will contain the following list of "standard" document description >language identifiers for printers in its Appendix C: In this phrasing, it seems that you're describing media types rather than devices, and that you might want to use application/postscript or some such. Larry Masinter Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333 Hi Harry: Please see my responses: At 12:55 PM 4/19/96 MDT, Harry Lewis wrote: >Ray - what is the intended use of "owner" or "company" in your PDL >naming scheme? Is it meant to distinguish between different vendor >implementations (or emulations) of the originally defined language >(ie clones)? No, the owner or company is meant as the owner of the remaining of the definition. To be more specific, I will quote from the IS-650 spec: **** Quote **** ::= {'|' } Some operands will reference a product, language, or format. The defined above provides a simple method which uses information generally available. Note that the vertical bar "|" is just a separator character and not a metalanguage "OR". For most applications, the will be formatted as Defining_Body|Model|Version|Serial_Number The "languageId" uses this form and are listed in ANNEX C. When the OBJECT IDENTIFIER form is desired, then the components of the OBJECT IDENTIFIER are listed in the same manner, using decimal notation for each of the components. (See ASN.1 for more information on OBJECT IDENTIFIERs.) **** Unquote **** Note that here, the first part is called "defining body". In many cases that will be a company or an organization. >Aside from the company part, your scheme seems to map >quite well into the existing Printer MIB. Granted, we only register >enums for the Family part (your PCL, PS etc.), but, looking at all your >examples, the lang level strings appear to easily be made unambiguous. I agree. Perhaps it would have made more sense to make this clear by the example, but this is what I have been requesting. The issue has been exactly how to make the version unambiguous, and if that is handled, than we should be able to create a one-to-one mapping. Now, I can't make such a map. To give you an idea of the company names already defined by SCSI, I have reproduced this list below. This is an extraction from the SCSI-3 "SPC" draft. **** Quote **** Vendor identification This annex contains the list of SCSI-3 vendor identifications (see table C.1) as of the date of this document. The purpose of this list is to help avoid redundant usage of vendor identifications. Technical Committee X3T10 of Accredited Standards Committee X3 maintains an informal list of vendor identifications currently in use. Please contact the chairman of X3T10 prior to using a new vendor identification to avoid conflicts. Table C.1 - Vendor identification list +===========-=================================================================+ | ID | Organization | |-----------+-----------------------------------------------------------------| | 3M | 3M Company | | ACL | Automated Cartridge Librarys, Inc. | | ADAPTEC | Adaptec | | ADSI | Adaptive Data Systems, Inc. (a Western Digital subsidiary) | | ADTX | ADTX Co., Ltd. | | AERONICS | Aeronics, Inc. | | AGFA | AGFA | | AMCODYNE | Amcodyne | | ANAMATIC | Anamartic Limited (England) | | ANCOT | ANCOT Corp. | | ANRITSU | Anritsu Corporation | | APPLE | Apple Computer, Inc. | | ARCHIVE | Archive | | ASACA | ASACA Corp. | | ASPEN | Aspen Peripherals | | AST | AST Research | | ASTK | Alcatel STK A/S | | AT&T | AT&T | | ATARI | Atari Corporation | | ATG CYG | ATG Cygnet Inc. | | ATTO | ATTO Technology Inc. | | ATX | Alphatronix | | AVR | Advanced Vision Research | | BALLARD | Ballard Synergy Corp. | | BERGSWD | Berg Software Design | | BEZIER | Bezier Systems, Inc. | | BULL | Bull Peripherals Corp. | | BUSLOGIC | BusLogic Inc. | | BiT | BiT Microsystems | | BoxHill | Box Hill Systems Corporation | | CALIPER | Caliper (California Peripheral Corp.) | | CAST | Advanced Storage Tech | | CDC | Control Data or MPI | | CDP | Columbia Data Products | | CHEROKEE | Cherokee Data Systems | | CHINON | Chinon | | CIE&YED | YE Data, C.Itoh Electric Corp. | | CIPHER | Cipher Data Products | | CIRRUSL | Cirrus Logic Inc. | | CMD | CMD Technology Inc. | | CNGR SFW | Congruent Software, Inc. | | COGITO | Cogito | | COMPORT | Comport Corp. | | COMPSIG | Computer Signal Corporation | | CONNER | Conner Peripherals | | CORE | Core International, Inc. | | CPU TECH | CPU Technology, Inc. | | CREO | Creo Products Inc. | | CROSFLD | Crosfield Electronics | | CSM, INC | Computer SM, Inc. | | CalComp | CalComp, A Lockheed Company | | Ciprico | Ciprico, Inc. | | DATABOOK | Databook, Inc. | | DATACOPY | Datacopy Corp. | | DATAPT | Datapoint Corp. | | DEC | Digital Equipment (Obsolete: New products use "Digital") | | DELPHI | Delphi Data Div. of Sparks Industries, Inc. | | DENON | Denon/Nippon Columbia | | DEST | DEST Corp. | | DGC | Data General Corp. | | DIGIDATA | Digi-Data Corporation | | DILOG | Distributed Logic Corp. | | DISC | Document Imaging Systems Corp. | | DPT | Distributed Processing Technology | | DSM | Deterner Steuerungs- und Maschinenbau GmbH & Co. | | DTC QUME | Data Technology Qume | | DXIMAGIN | DX Imaging | | Digital | Digital Equipment Corporation | | EMC | EMC Corp. | | EMULEX | Emulex | | EPSON | Epson | | Eris/RSI | RSI Systems, Inc. | | EXABYTE | Exabyte Corp. | | FILENET | FileNet Corp. | | FRAMDRV | FRAMEDRIVE Corp. | | FUJI | Fuji Electric Co., Ltd. (Japan) | | FUJITSU | Fujitsu | | FUNAI | Funai Electric Co., Ltd. | | FUTURED | Future Domain Corp. | | GIGATAPE | GIGATAPE GmbH | | GIGATRND | GigaTrend Incorporated | | GOULD | Gould | | Gen_Dyn | General Dynamics | | Goidelic | Goidelic Precision, Inc. | | HITACHI | Hitachi America Ltd or Nissei Sangyo America Ltd | | HONEYWEL | Honeywell Inc. | | HP | Hewlett Packard | | i-cubed | i-cubed ltd. | | IBM | International Business Machines | | ICL | ICL | | IDE | International Data Engineering, Inc. | | IGR | Intergraph Corp. | | IMPLTD | Integrated Micro Products Ltd. | | IMPRIMIS | Imprimis Technology Inc. | | INSITE | Insite Peripherals | | INTEL | Intel Corporation | | IOC | I/O Concepts, Inc. | | IOMEGA | Iomega | | ISi | Information Storage inc. | | ITC | International Tapetronics Corporation | | JPC Inc. | JPC Inc. | | JVC | JVC Information Products Co. | | KENNEDY | Kennedy Company | | KODAK | Eastman Kodak | | KONAN | Konan | | KONICA | Konica Japan | | LAPINE | Lapine Technology | | LASERDRV | LaserDrive Limited | | LASERGR | Lasergraphics, Inc. | | LION | Lion Optics Corporation | | LMS | Laser Magnetic Storage International Company | | MATSHITA | Matsushita | | MAXSTRAT | Maximum Strategy, Inc. | | MAXTOR | Maxtor Corp. | | MDI | Micro Design International, Inc. | | MEADE | Meade Instruments Corporation | | MELA | Mitsubishi Electronics America | | MELCO | Mitsubishi Electric (Japan) | | MEMREL | Memrel Corporation | | MEMTECH | MemTech Technology | | MERIDATA | Oy Meridata Finland Ltd. | | METRUM | Metrum, Inc. | | MICROBTX | Microbotics Inc. | | MICROP | Micropolis | | MICROTEK | Microtek Storage Corp | | MINSCRIB | Miniscribe | | MITSUMI | Mitsumi Electric Co., Ltd. | | MOTOROLA | Motorola | | MST | Morning Star Technologies, Inc. | | MTNGATE | MountainGate Data Systems | | MaxOptix | Maxoptix Corp. | | Minitech | Minitech (UK) Limited | | Minolta | Minolta Corporation | | NAI | North Atlantic Industries | | NCL | NCL America | | NCR | NCR Corporation | | NEC | NEC | | NISCA | NISCA Inc. | | NKK | NKK Corp. | | NRC | Nakamichi Corporation | | NSM | NSM Jukebox GmbH | | NT | Northern Telecom | | NatInst | National Instruments | | NatSemi | National Semiconductor Corp. | | OAI | Optical Access International | | OCE | Oce Graphics | | OKI | OKI Electric Industry Co.,Ltd (Japan) | | OMI | Optical Media International | | OMNIS | OMNIS Company (FRANCE) | | OPTIMEM | Cipher/Optimem | | OPTOTECH | Optotech | | ORCA | Orca Technology | | OSI | Optical Storage International | | OTL | OTL Engineering | | PASCOsci | Pasco Scientific | | PERTEC | Pertec Peripherals Corporation | | PFTI | Performance Technology Inc. | | PFU | PFU Limited | | PIONEER | Pioneer Electronic Corp. | | PRAIRIE | PrairieTek | | PREPRESS | PrePRESS Solutions | | PRESOFT | PreSoft Architects | | PRESTON | Preston Scientific | | PRIAM | Priam | | PRIMAGFX | Primagraphics Ltd | | PTI | Peripheral Technology Inc. | | QIC | Quarter-Inch Cartridge Drive Standards, Inc. | | QUALSTAR | Qualstar | | QUANTUM | Quantum Corp. | | QUANTEL | Quantel Ltd. | | R-BYTE | R-Byte, Inc. | | RACALREC | Racal Recorders | | RADSTONE | Radstone Technology | | RGI | Raster Graphics, Inc. | | RICOH | Ricoh | | RODIME | Rodime | | RTI | Reference Technology | | SAMSUNG | Samsung Electronics Co., Ltd. | | SANKYO | Sankyo Seiki | | SANYO | SANYO Electric Co., Ltd. | | SCREEN | Dainippon Screen Mfg. Co., Ltd. | | SEAGATE | Seagate | | SEQUOIA | Sequoia Advanced Technologies, Inc. | | SIEMENS | Siemens | | SII | Seiko Instruments Inc. | | SMS | Scientific Micro Systems/OMTI | | SNYSIDE | Sunnyside Computing Inc. | | SONIC | Sonic Solutions | | SONY | Sony Corporation Japan | | SPECIAL | Special Computing Co. | | SPECTRA | Spectra Logic, a Division of Western Automation Labs, Inc. | | SPERRY | Sperry (now Unisys Corp.) | | STK | Storage Technology Corporation | | SUMITOMO | Sumitomo Electric Industries, Ltd. | | SUN | Sun Microsystems, Inc. | | SYMBIOS | Symbios Logic Inc. | | SYSGEN | Sysgen | | Shinko | Shinko Electric Co., Ltd. | | SyQuest | SyQuest Technology, Inc. | | T-MITTON | Transmitton England | | TALARIS | Talaris Systems, Inc. | | TALLGRAS | Tallgrass Technologies | | TANDBERG | Tandberg Data A/S | | TANDON | Tandon | | TEAC | TEAC Japan | | TECOLOTE | Tecolote Designs | | TEGRA | Tegra Varityper | | TENTIME | Laura Technologies, Inc. | | TI-DSG | Texas Instruments | | TOSHIBA | Toshiba Japan | | Tek | Tektronix | | ULTRA | UltraStor Corporation | | UNISYS | Unisys | | USDC | US Design Corp. | | VERBATIM | Verbatim Corporation | | VEXCEL | VEXCEL IMAGING GmbH | | VRC | Vermont Research Corp. | | WANGTEK | Wangtek | | WDIGTL | Western Digital | | WEARNES | Wearnes Technology Corporation | | WangDAT | WangDAT | | X3 | Accredited Standards Committee X3, Information Technology | | XEBEC | Xebec Corporation | +=============================================================================+ **** Unquote ***** -Raymond Hi Larry: Please see my response below: At 02:43 PM 4/21/96 PDT, Larry Masinter wrote: >Is the PDL naming scheme describing the device, or is it describing >the media that the device accepts? Well, let's not use the term "Media". That sounds like paper or transparencies, etc. to me. If we use "File Format" or "Format and Protocol" I will go along with that. >In this phrasing, it seems that you're describing media types rather >than devices, and that you might want to use application/postscript or >some such. That is exactly the right idea! You are pulling on the MIME methodology here, which is good, and it reflects correctly, I believe, on what we want to express, albeit not precisely enough. The Printer Working Group has chosen to be "program-specific" since it is talking about what interpreter exists in the device. I can see some need to describe the vendor, version, serial number, etc. of the exact piece of code in the device. However, that piece of code is designed around some standard or language description, and this is also needed. Perhaps an example is better here. Let's take Postscript. We have two major versions of this format/protocol, as follows: ADOBE|PS|1 ADOBE|PS|2 Ok, I am saying that ADOBE is the "Defining Body" of the specification, the specification is Postscript ("PS"), and the version is 1 or 2. These are more than just file formats since Postscript is in general also a protocol since it can involve interactive give and take. Now, we can have interpreters that are designed to use the, say, ADOBE|PS|2 language. A number of vendors may build such an animal, and in fact a given vendor may have a number of versions of this animal, each one approaching the specification to a different degree. As we all know, any english specification is insufficient to describe all the intricacies of such a protocol, and so it is nice to know what version the implementation is as well. This interpreter make and model are also defined in MFPI IS-650 using the same format. In this example, we may have say "XIONICS|4.5|F" meaning that this is a Xionics Interpreter (which may indeed be built on top of other code, such as that from Adobe), version 4.5, revision F. Although heavily related, I would hate to see us merge these into a single enum. I would hope that there is some interoperability testing among these various generations of interpreters and drivers such that they can interoperate without having too many variations on a theme introduced by the specific implementation of the language. If that is the case, there is not much use in having standards at all. The other issue here is that the "Interpreters" as specified may not be separate animals at all, but indeed, simply a subset of the capability of a larger system. Therefore, the using only the specification of the interpreter code is fraught with defects that will only continue to haunt us. You may be asking "Why be so precise -- Why not use the definitions for body types from MIME". I would be happy to be able to use the MIME types, but they are insufficient when a PDL is sent to a receiving Dial-up device for printing without user interaction. You see, MIME assumes a great deal of user interaction which we do not have the luxury of in the case of MFP's with no attached user, but still the desire to render and print the document at the dial-up site. >Larry Masinter Xerox Palo Alto Research Center (PARC) >3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333 > thanks for your comment! Regards, -Raymond Please complete the member survey this week. I am retransmitting it in case you have forgotten. DON'T PROCRASTINATE -- DO IT NOW! DN:MFPA-96-017 MFPA 1996 MEMBER SURVEY ----------------------- Purpose: HELP CHART THE COURSE OF THE MFPA! This survey is intended to provide new direction and/or validate the current direction of the MFPA working group(s), and the attention that we give to established standards groups that are not part of the MFPA. It is understood that it is inconvenient or impossible for all member companies to attend quarterly and working group meetings that are held more often. Therefore, as a member of MFPA, please complete the following questionaire. We will then summarize the results. Your responses are strictly confidential and your company identity will not be revealed with the results of this questionaire. TimeFrame: Please consider the questions carefully and respond by Friday, 4/26/1996. -----> DUE FRIDAY, 4/26/1996 <----- Please return the questionaire promptly so that we may compile the results for the upcoming meeting 5/1-2/1996. Questionaire Method: Many of the questions below are qualitative in nature. The following scale will be used for these questions: 0 - I don't know the answer or can't rate this 1 - Poor, Way too little, Needs much improvement 2 - Fair, Slightly too little, Needs some improvement 3 - Good, About right 4 - Extra, Slightly too much, Slight reduction in Costs here 5 - Excessive, Way too much, Major reduction in Costs here 1 - TECHNICAL ============= On what should the MFPA be spending time and energy? Please indicate your interest level in each of the following technical initiatives. Use 1-5, where 1 is the highest interest, and 5 is lowest interest. 1-1) [ ] Complete MFPI-1 IS-650 as an industry standard. 1-2) [ ] Work on MFPI-2 for Fax 1-3) [ ] Work on MFPI-2 for Printing 1-4) [ ] Work on MFPI-2 for Scanning 1-5) [ ] Work on MFPI-3 1-6) [ ] Work on MFPI-4 1-7) [ ] Map MFPI-1 to SCSI 1-8) [ ] Map MFPI-1 to HP-MLC and IEEE-1284.4 1-9) [ ] Map MFPI-1 to IEEE-1394 1-10) [ ] Map MFPI-1 to USB 1-11) [ ] Transportable Document Format (TDF) and InterDomain Job Submission 1-12) [ ] Improved T.30 Protocol (Integrated with Internet) 1-13) [ ] Troika API 1-14) [ ] MFP Levels of Service and graphic designation 1-15) [ ] MFP MIB 1-16) [ ] Scanner MIB 1-17) [ ] Internal MFP interconnect standards (scanner, printer, etc.) 1-18) [ ] Harmonization with Novell NDPS and NEST 1-19) [ ] CORBA and OLE integration of services in MFP. 1-20) [ ] Fax "routing" issues 1-21) [ ] Fax Extended Negotiations Protocols (ENPs) 1-22) [ ] IS-101 related voice-modem (answering machine) stds 1-23) [ ] Simultaneous voice/data (SVD) technologies 1-24) [ ] Simultaneous voice/fax technologies 1-25) [ ] Facsimile security 1-26) [ ] MFP Operator Console standards 1-27) [ ] Phonebooks standards (Bentograms, etc) 1-28) [ ] Test Suites for MFPI, various levels 1-29) [ ] Interoperability standards for MFPI 1-30) [ ] Generation of standard VxD and sample code for MFPI-1 1-31) [ ] High-Speed facsimile 1-32) [ ] Quality conformance standards for MFPs 1-33) [ ] Enhancement of T.611 Fax API for MFPs 1-34) [ ] Enhancement of DPA for MFPs 1-35) [ ] Generation of Class-3 fax standard 1-36) [ ] BFT enhancement 1-37) [ ] BFT interoperability 1-38) [ ] Remote rendering of printed documents on MFPs, but not TDF. 1-39) [ ] Harmonization with Adobe PDF and other initiatives 1-40) [ ] TIA TR29.1, Facsimile Protocols (improved PSTN protocols, BFT) 1-41) [ ] TIA TR29.2, DTE/DCE protocols (EX: MFPI, Class1, Class2, etc.) 1-42) [ ] TIA TR30 (Data Modem Standards Committees), Generally 1-43) [ ] IEEE-1284.1, TIPSI - Transport Independent Printer Systems Interface 1-44) [ ] IEEE-1284.2, IEEE-1284 testing 1-45) [ ] IEEE-1284.3, Daisy-chain and mux enhancements for IEEE-1284 1-46) [ ] IEEE-1284.4, Standardization of HP-MLC protocol 1-47) [ ] PWG: Printer Working Group, SNMP management of printers 1-48) [ ] DMTF, Desktop Management Task Force 1-49) [ ] Salutation Consortium 1-50) [ ] Electronic Mail Association (EMA) 1-51) [ ] AIIM, Generally 1-52) [ ] AIIM, MS-53 committee standardizing compressed image formats 1-53) [ ] AIIM, MS-64 committee standardizing ISIS scanner interface 1-54) [ ] TWAIN scanner API 1-55) [ ] IETF, Internet Engineering Task Force 1-56) [ ] ICTF, Integrated Communication Architecture 1-57) [ ] IRDA, Infrared Data Assocation 1-58) [ ] USB, Universal Serial Bus 1-59) [ ] IEEE-1394 Trade Association and "FireWire" involvement 1-60) [ ] X-3 SCSI Standards committees 1-61) [ ] CORBA: Common Object Request Broker Architecture 1-62) [ ] NetWare NDPS Architecture 1-63) [ ] NetWare NEST: NetWare Embedded Systems Technology 1-64) [ ] Wordcraft Computer Fax Protocol (CFP) 1-65) [ ] Versit Computer Telephony and Personal Data Interchange 1-66) [ ] ISO-10175 Document Printing Architecture 1-67) [ ] Other: 1-68) [ ] Other: 1-69) Comments and suggestions on Techinical Initiatives: 2 - ADMINISTRATION ================== 2-1) [ ] Rate the overall amount of service provided to members (0-5). 2-2) [ ] Rate the effectiveness and quality of quarterly meetings (0-5). 2-3) [ ] Rate the effectiveness and quality of working group meetings (0-5). 2-4) Please provide your first choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-5) Please provide your second choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-6) [ ] Rate the meeting geographical locations selected to date. 2-7) [ ] Rate the meeting site, rooms, costs, etc. 2-8) [ ] Would you be interested in sponsoring an MFPA meeting in your area? (Y/N) 2-9) [ ] Would you support meeting charges for the attendees if the meeting is not sponsored? (perhaps $25/day) (Y/N) 2-10) [ ] Rate the membership dues for members (0-5) 2-11) [ ] Rate your involvement and participation with the MFPA NOW (0-5) 2-12) [ ] Rate your future involvement and participation with the MFPA (0-5) 2-13) Comments and Suggestions on Administration topics: 2-14) What would allow you to attend more meetings? 3 - MARKETING ============= Web Site -------- 3-1) [ ] Rate the Web Site, in general. 3-2) [ ] Should draft documents of the MFPA be in a private area of the web site? (Y/N) 3-3) Suggestions for additions to the MFPA Web Site: Tradeshows ---------- 3-4) [ ] Rate the exposure of MFPA at the COMDEX tradeshow (0-5) 3-5) [ ] Rate the exposure of MFPA at the BTA tradeshow (0-5) 3-6) Suggestions for exposure and participation at tradeshows: General ------- 3-7) Suggestions for general marketing and exposure of the MFPA: /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Harry: Please see my responses: At 12:55 PM 4/19/96 MDT, Harry Lewis wrote: >Ray - what is the intended use of "owner" or "company" in your PDL >naming scheme? Is it meant to distinguish between different vendor >implementations (or emulations) of the originally defined language >(ie clones)? No, the owner or company is meant as the owner of the remaining of the definition. To be more specific, I will quote from the IS-650 spec: **** Quote **** ::= {'|' } Some operands will reference a product, language, or format. The defined above provides a simple method which uses information generally available. Note that the vertical bar "|" is just a separator character and not a metalanguage "OR". For most applications, the will be formatted as Defining_Body|Model|Version|Serial_Number The "languageId" uses this form and are listed in ANNEX C. When the OBJECT IDENTIFIER form is desired, then the components of the OBJECT IDENTIFIER are listed in the same manner, using decimal notation for each of the components. (See ASN.1 for more information on OBJECT IDENTIFIERs.) **** Unquote **** Note that here, the first part is called "defining body". In many cases that will be a company or an organization. >Aside from the company part, your scheme seems to map >quite well into the existing Printer MIB. Granted, we only register >enums for the Family part (your PCL, PS etc.), but, looking at all your >examples, the lang level strings appear to easily be made unambiguous. I agree. Perhaps it would have made more sense to make this clear by the example, but this is what I have been requesting. The issue has been exactly how to make the version unambiguous, and if that is handled, than we should be able to create a one-to-one mapping. Now, I can't make such a map. To give you an idea of the company names already defined by SCSI, I have reproduced this list below. This is an extraction from the SCSI-3 "SPC" draft. **** Quote **** Vendor identification This annex contains the list of SCSI-3 vendor identifications (see table C.1) as of the date of this document. The purpose of this list is to help avoid redundant usage of vendor identifications. Technical Committee X3T10 of Accredited Standards Committee X3 maintains an informal list of vendor identifications currently in use. Please contact the chairman of X3T10 prior to using a new vendor identification to avoid conflicts. Table C.1 - Vendor identification list +===========-=================================================================+ | ID | Organization | |-----------+-----------------------------------------------------------------| | 3M | 3M Company | | ACL | Automated Cartridge Librarys, Inc. | | ADAPTEC | Adaptec | | ADSI | Adaptive Data Systems, Inc. (a Western Digital subsidiary) | | ADTX | ADTX Co., Ltd. | | AERONICS | Aeronics, Inc. | | AGFA | AGFA | | AMCODYNE | Amcodyne | | ANAMATIC | Anamartic Limited (England) | | ANCOT | ANCOT Corp. | | ANRITSU | Anritsu Corporation | | APPLE | Apple Computer, Inc. | | ARCHIVE | Archive | | ASACA | ASACA Corp. | | ASPEN | Aspen Peripherals | | AST | AST Research | | ASTK | Alcatel STK A/S | | AT&T | AT&T | | ATARI | Atari Corporation | | ATG CYG | ATG Cygnet Inc. | | ATTO | ATTO Technology Inc. | | ATX | Alphatronix | | AVR | Advanced Vision Research | | BALLARD | Ballard Synergy Corp. | | BERGSWD | Berg Software Design | | BEZIER | Bezier Systems, Inc. | | BULL | Bull Peripherals Corp. | | BUSLOGIC | BusLogic Inc. | | BiT | BiT Microsystems | | BoxHill | Box Hill Systems Corporation | | CALIPER | Caliper (California Peripheral Corp.) | | CAST | Advanced Storage Tech | | CDC | Control Data or MPI | | CDP | Columbia Data Products | | CHEROKEE | Cherokee Data Systems | | CHINON | Chinon | | CIE&YED | YE Data, C.Itoh Electric Corp. | | CIPHER | Cipher Data Products | | CIRRUSL | Cirrus Logic Inc. | | CMD | CMD Technology Inc. | | CNGR SFW | Congruent Software, Inc. | | COGITO | Cogito | | COMPORT | Comport Corp. | | COMPSIG | Computer Signal Corporation | | CONNER | Conner Peripherals | | CORE | Core International, Inc. | | CPU TECH | CPU Technology, Inc. | | CREO | Creo Products Inc. | | CROSFLD | Crosfield Electronics | | CSM, INC | Computer SM, Inc. | | CalComp | CalComp, A Lockheed Company | | Ciprico | Ciprico, Inc. | | DATABOOK | Databook, Inc. | | DATACOPY | Datacopy Corp. | | DATAPT | Datapoint Corp. | | DEC | Digital Equipment (Obsolete: New products use "Digital") | | DELPHI | Delphi Data Div. of Sparks Industries, Inc. | | DENON | Denon/Nippon Columbia | | DEST | DEST Corp. | | DGC | Data General Corp. | | DIGIDATA | Digi-Data Corporation | | DILOG | Distributed Logic Corp. | | DISC | Document Imaging Systems Corp. | | DPT | Distributed Processing Technology | | DSM | Deterner Steuerungs- und Maschinenbau GmbH & Co. | | DTC QUME | Data Technology Qume | | DXIMAGIN | DX Imaging | | Digital | Digital Equipment Corporation | | EMC | EMC Corp. | | EMULEX | Emulex | | EPSON | Epson | | Eris/RSI | RSI Systems, Inc. | | EXABYTE | Exabyte Corp. | | FILENET | FileNet Corp. | | FRAMDRV | FRAMEDRIVE Corp. | | FUJI | Fuji Electric Co., Ltd. (Japan) | | FUJITSU | Fujitsu | | FUNAI | Funai Electric Co., Ltd. | | FUTURED | Future Domain Corp. | | GIGATAPE | GIGATAPE GmbH | | GIGATRND | GigaTrend Incorporated | | GOULD | Gould | | Gen_Dyn | General Dynamics | | Goidelic | Goidelic Precision, Inc. | | HITACHI | Hitachi America Ltd or Nissei Sangyo America Ltd | | HONEYWEL | Honeywell Inc. | | HP | Hewlett Packard | | i-cubed | i-cubed ltd. | | IBM | International Business Machines | | ICL | ICL | | IDE | International Data Engineering, Inc. | | IGR | Intergraph Corp. | | IMPLTD | Integrated Micro Products Ltd. | | IMPRIMIS | Imprimis Technology Inc. | | INSITE | Insite Peripherals | | INTEL | Intel Corporation | | IOC | I/O Concepts, Inc. | | IOMEGA | Iomega | | ISi | Information Storage inc. | | ITC | International Tapetronics Corporation | | JPC Inc. | JPC Inc. | | JVC | JVC Information Products Co. | | KENNEDY | Kennedy Company | | KODAK | Eastman Kodak | | KONAN | Konan | | KONICA | Konica Japan | | LAPINE | Lapine Technology | | LASERDRV | LaserDrive Limited | | LASERGR | Lasergraphics, Inc. | | LION | Lion Optics Corporation | | LMS | Laser Magnetic Storage International Company | | MATSHITA | Matsushita | | MAXSTRAT | Maximum Strategy, Inc. | | MAXTOR | Maxtor Corp. | | MDI | Micro Design International, Inc. | | MEADE | Meade Instruments Corporation | | MELA | Mitsubishi Electronics America | | MELCO | Mitsubishi Electric (Japan) | | MEMREL | Memrel Corporation | | MEMTECH | MemTech Technology | | MERIDATA | Oy Meridata Finland Ltd. | | METRUM | Metrum, Inc. | | MICROBTX | Microbotics Inc. | | MICROP | Micropolis | | MICROTEK | Microtek Storage Corp | | MINSCRIB | Miniscribe | | MITSUMI | Mitsumi Electric Co., Ltd. | | MOTOROLA | Motorola | | MST | Morning Star Technologies, Inc. | | MTNGATE | MountainGate Data Systems | | MaxOptix | Maxoptix Corp. | | Minitech | Minitech (UK) Limited | | Minolta | Minolta Corporation | | NAI | North Atlantic Industries | | NCL | NCL America | | NCR | NCR Corporation | | NEC | NEC | | NISCA | NISCA Inc. | | NKK | NKK Corp. | | NRC | Nakamichi Corporation | | NSM | NSM Jukebox GmbH | | NT | Northern Telecom | | NatInst | National Instruments | | NatSemi | National Semiconductor Corp. | | OAI | Optical Access International | | OCE | Oce Graphics | | OKI | OKI Electric Industry Co.,Ltd (Japan) | | OMI | Optical Media International | | OMNIS | OMNIS Company (FRANCE) | | OPTIMEM | Cipher/Optimem | | OPTOTECH | Optotech | | ORCA | Orca Technology | | OSI | Optical Storage International | | OTL | OTL Engineering | | PASCOsci | Pasco Scientific | | PERTEC | Pertec Peripherals Corporation | | PFTI | Performance Technology Inc. | | PFU | PFU Limited | | PIONEER | Pioneer Electronic Corp. | | PRAIRIE | PrairieTek | | PREPRESS | PrePRESS Solutions | | PRESOFT | PreSoft Architects | | PRESTON | Preston Scientific | | PRIAM | Priam | | PRIMAGFX | Primagraphics Ltd | | PTI | Peripheral Technology Inc. | | QIC | Quarter-Inch Cartridge Drive Standards, Inc. | | QUALSTAR | Qualstar | | QUANTUM | Quantum Corp. | | QUANTEL | Quantel Ltd. | | R-BYTE | R-Byte, Inc. | | RACALREC | Racal Recorders | | RADSTONE | Radstone Technology | | RGI | Raster Graphics, Inc. | | RICOH | Ricoh | | RODIME | Rodime | | RTI | Reference Technology | | SAMSUNG | Samsung Electronics Co., Ltd. | | SANKYO | Sankyo Seiki | | SANYO | SANYO Electric Co., Ltd. | | SCREEN | Dainippon Screen Mfg. Co., Ltd. | | SEAGATE | Seagate | | SEQUOIA | Sequoia Advanced Technologies, Inc. | | SIEMENS | Siemens | | SII | Seiko Instruments Inc. | | SMS | Scientific Micro Systems/OMTI | | SNYSIDE | Sunnyside Computing Inc. | | SONIC | Sonic Solutions | | SONY | Sony Corporation Japan | | SPECIAL | Special Computing Co. | | SPECTRA | Spectra Logic, a Division of Western Automation Labs, Inc. | | SPERRY | Sperry (now Unisys Corp.) | | STK | Storage Technology Corporation | | SUMITOMO | Sumitomo Electric Industries, Ltd. | | SUN | Sun Microsystems, Inc. | | SYMBIOS | Symbios Logic Inc. | | SYSGEN | Sysgen | | Shinko | Shinko Electric Co., Ltd. | | SyQuest | SyQuest Technology, Inc. | | T-MITTON | Transmitton England | | TALARIS | Talaris Systems, Inc. | | TALLGRAS | Tallgrass Technologies | | TANDBERG | Tandberg Data A/S | | TANDON | Tandon | | TEAC | TEAC Japan | | TECOLOTE | Tecolote Designs | | TEGRA | Tegra Varityper | | TENTIME | Laura Technologies, Inc. | | TI-DSG | Texas Instruments | | TOSHIBA | Toshiba Japan | | Tek | Tektronix | | ULTRA | UltraStor Corporation | | UNISYS | Unisys | | USDC | US Design Corp. | | VERBATIM | Verbatim Corporation | | VEXCEL | VEXCEL IMAGING GmbH | | VRC | Vermont Research Corp. | | WANGTEK | Wangtek | | WDIGTL | Western Digital | | WEARNES | Wearnes Technology Corporation | | WangDAT | WangDAT | | X3 | Accredited Standards Committee X3, Information Technology | | XEBEC | Xebec Corporation | +=============================================================================+ **** Unquote ***** -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Harry: Please see my responses: At 12:55 PM 4/19/96 MDT, Harry Lewis wrote: >Ray - what is the intended use of "owner" or "company" in your PDL >naming scheme? Is it meant to distinguish between different vendor >implementations (or emulations) of the originally defined language >(ie clones)? No, the owner or company is meant as the owner of the remaining of the definition. To be more specific, I will quote from the IS-650 spec: **** Quote **** ::= {'|' } Some operands will reference a product, language, or format. The defined above provides a simple method which uses information generally available. Note that the vertical bar "|" is just a separator character and not a metalanguage "OR". For most applications, the will be formatted as Defining_Body|Model|Version|Serial_Number The "languageId" uses this form and are listed in ANNEX C. When the OBJECT IDENTIFIER form is desired, then the components of the OBJECT IDENTIFIER are listed in the same manner, using decimal notation for each of the components. (See ASN.1 for more information on OBJECT IDENTIFIERs.) **** Unquote **** Note that here, the first part is called "defining body". In many cases that will be a company or an organization. >Aside from the company part, your scheme seems to map >quite well into the existing Printer MIB. Granted, we only register >enums for the Family part (your PCL, PS etc.), but, looking at all your >examples, the lang level strings appear to easily be made unambiguous. I agree. Perhaps it would have made more sense to make this clear by the example, but this is what I have been requesting. The issue has been exactly how to make the version unambiguous, and if that is handled, than we should be able to create a one-to-one mapping. Now, I can't make such a map. To give you an idea of the company names already defined by SCSI, I have reproduced this list below. This is an extraction from the SCSI-3 "SPC" draft. **** Quote **** Vendor identification This annex contains the list of SCSI-3 vendor identifications (see table C.1) as of the date of this document. The purpose of this list is to help avoid redundant usage of vendor identifications. Technical Committee X3T10 of Accredited Standards Committee X3 maintains an informal list of vendor identifications currently in use. Please contact the chairman of X3T10 prior to using a new vendor identification to avoid conflicts. Table C.1 - Vendor identification list +===========-=================================================================+ | ID | Organization | |-----------+-----------------------------------------------------------------| | 3M | 3M Company | | ACL | Automated Cartridge Librarys, Inc. | | ADAPTEC | Adaptec | | ADSI | Adaptive Data Systems, Inc. (a Western Digital subsidiary) | | ADTX | ADTX Co., Ltd. | | AERONICS | Aeronics, Inc. | | AGFA | AGFA | | AMCODYNE | Amcodyne | | ANAMATIC | Anamartic Limited (England) | | ANCOT | ANCOT Corp. | | ANRITSU | Anritsu Corporation | | APPLE | Apple Computer, Inc. | | ARCHIVE | Archive | | ASACA | ASACA Corp. | | ASPEN | Aspen Peripherals | | AST | AST Research | | ASTK | Alcatel STK A/S | | AT&T | AT&T | | ATARI | Atari Corporation | | ATG CYG | ATG Cygnet Inc. | | ATTO | ATTO Technology Inc. | | ATX | Alphatronix | | AVR | Advanced Vision Research | | BALLARD | Ballard Synergy Corp. | | BERGSWD | Berg Software Design | | BEZIER | Bezier Systems, Inc. | | BULL | Bull Peripherals Corp. | | BUSLOGIC | BusLogic Inc. | | BiT | BiT Microsystems | | BoxHill | Box Hill Systems Corporation | | CALIPER | Caliper (California Peripheral Corp.) | | CAST | Advanced Storage Tech | | CDC | Control Data or MPI | | CDP | Columbia Data Products | | CHEROKEE | Cherokee Data Systems | | CHINON | Chinon | | CIE&YED | YE Data, C.Itoh Electric Corp. | | CIPHER | Cipher Data Products | | CIRRUSL | Cirrus Logic Inc. | | CMD | CMD Technology Inc. | | CNGR SFW | Congruent Software, Inc. | | COGITO | Cogito | | COMPORT | Comport Corp. | | COMPSIG | Computer Signal Corporation | | CONNER | Conner Peripherals | | CORE | Core International, Inc. | | CPU TECH | CPU Technology, Inc. | | CREO | Creo Products Inc. | | CROSFLD | Crosfield Electronics | | CSM, INC | Computer SM, Inc. | | CalComp | CalComp, A Lockheed Company | | Ciprico | Ciprico, Inc. | | DATABOOK | Databook, Inc. | | DATACOPY | Datacopy Corp. | | DATAPT | Datapoint Corp. | | DEC | Digital Equipment (Obsolete: New products use "Digital") | | DELPHI | Delphi Data Div. of Sparks Industries, Inc. | | DENON | Denon/Nippon Columbia | | DEST | DEST Corp. | | DGC | Data General Corp. | | DIGIDATA | Digi-Data Corporation | | DILOG | Distributed Logic Corp. | | DISC | Document Imaging Systems Corp. | | DPT | Distributed Processing Technology | | DSM | Deterner Steuerungs- und Maschinenbau GmbH & Co. | | DTC QUME | Data Technology Qume | | DXIMAGIN | DX Imaging | | Digital | Digital Equipment Corporation | | EMC | EMC Corp. | | EMULEX | Emulex | | EPSON | Epson | | Eris/RSI | RSI Systems, Inc. | | EXABYTE | Exabyte Corp. | | FILENET | FileNet Corp. | | FRAMDRV | FRAMEDRIVE Corp. | | FUJI | Fuji Electric Co., Ltd. (Japan) | | FUJITSU | Fujitsu | | FUNAI | Funai Electric Co., Ltd. | | FUTURED | Future Domain Corp. | | GIGATAPE | GIGATAPE GmbH | | GIGATRND | GigaTrend Incorporated | | GOULD | Gould | | Gen_Dyn | General Dynamics | | Goidelic | Goidelic Precision, Inc. | | HITACHI | Hitachi America Ltd or Nissei Sangyo America Ltd | | HONEYWEL | Honeywell Inc. | | HP | Hewlett Packard | | i-cubed | i-cubed ltd. | | IBM | International Business Machines | | ICL | ICL | | IDE | International Data Engineering, Inc. | | IGR | Intergraph Corp. | | IMPLTD | Integrated Micro Products Ltd. | | IMPRIMIS | Imprimis Technology Inc. | | INSITE | Insite Peripherals | | INTEL | Intel Corporation | | IOC | I/O Concepts, Inc. | | IOMEGA | Iomega | | ISi | Information Storage inc. | | ITC | International Tapetronics Corporation | | JPC Inc. | JPC Inc. | | JVC | JVC Information Products Co. | | KENNEDY | Kennedy Company | | KODAK | Eastman Kodak | | KONAN | Konan | | KONICA | Konica Japan | | LAPINE | Lapine Technology | | LASERDRV | LaserDrive Limited | | LASERGR | Lasergraphics, Inc. | | LION | Lion Optics Corporation | | LMS | Laser Magnetic Storage International Company | | MATSHITA | Matsushita | | MAXSTRAT | Maximum Strategy, Inc. | | MAXTOR | Maxtor Corp. | | MDI | Micro Design International, Inc. | | MEADE | Meade Instruments Corporation | | MELA | Mitsubishi Electronics America | | MELCO | Mitsubishi Electric (Japan) | | MEMREL | Memrel Corporation | | MEMTECH | MemTech Technology | | MERIDATA | Oy Meridata Finland Ltd. | | METRUM | Metrum, Inc. | | MICROBTX | Microbotics Inc. | | MICROP | Micropolis | | MICROTEK | Microtek Storage Corp | | MINSCRIB | Miniscribe | | MITSUMI | Mitsumi Electric Co., Ltd. | | MOTOROLA | Motorola | | MST | Morning Star Technologies, Inc. | | MTNGATE | MountainGate Data Systems | | MaxOptix | Maxoptix Corp. | | Minitech | Minitech (UK) Limited | | Minolta | Minolta Corporation | | NAI | North Atlantic Industries | | NCL | NCL America | | NCR | NCR Corporation | | NEC | NEC | | NISCA | NISCA Inc. | | NKK | NKK Corp. | | NRC | Nakamichi Corporation | | NSM | NSM Jukebox GmbH | | NT | Northern Telecom | | NatInst | National Instruments | | NatSemi | National Semiconductor Corp. | | OAI | Optical Access International | | OCE | Oce Graphics | | OKI | OKI Electric Industry Co.,Ltd (Japan) | | OMI | Optical Media International | | OMNIS | OMNIS Company (FRANCE) | | OPTIMEM | Cipher/Optimem | | OPTOTECH | Optotech | | ORCA | Orca Technology | | OSI | Optical Storage International | | OTL | OTL Engineering | | PASCOsci | Pasco Scientific | | PERTEC | Pertec Peripherals Corporation | | PFTI | Performance Technology Inc. | | PFU | PFU Limited | | PIONEER | Pioneer Electronic Corp. | | PRAIRIE | PrairieTek | | PREPRESS | PrePRESS Solutions | | PRESOFT | PreSoft Architects | | PRESTON | Preston Scientific | | PRIAM | Priam | | PRIMAGFX | Primagraphics Ltd | | PTI | Peripheral Technology Inc. | | QIC | Quarter-Inch Cartridge Drive Standards, Inc. | | QUALSTAR | Qualstar | | QUANTUM | Quantum Corp. | | QUANTEL | Quantel Ltd. | | R-BYTE | R-Byte, Inc. | | RACALREC | Racal Recorders | | RADSTONE | Radstone Technology | | RGI | Raster Graphics, Inc. | | RICOH | Ricoh | | RODIME | Rodime | | RTI | Reference Technology | | SAMSUNG | Samsung Electronics Co., Ltd. | | SANKYO | Sankyo Seiki | | SANYO | SANYO Electric Co., Ltd. | | SCREEN | Dainippon Screen Mfg. Co., Ltd. | | SEAGATE | Seagate | | SEQUOIA | Sequoia Advanced Technologies, Inc. | | SIEMENS | Siemens | | SII | Seiko Instruments Inc. | | SMS | Scientific Micro Systems/OMTI | | SNYSIDE | Sunnyside Computing Inc. | | SONIC | Sonic Solutions | | SONY | Sony Corporation Japan | | SPECIAL | Special Computing Co. | | SPECTRA | Spectra Logic, a Division of Western Automation Labs, Inc. | | SPERRY | Sperry (now Unisys Corp.) | | STK | Storage Technology Corporation | | SUMITOMO | Sumitomo Electric Industries, Ltd. | | SUN | Sun Microsystems, Inc. | | SYMBIOS | Symbios Logic Inc. | | SYSGEN | Sysgen | | Shinko | Shinko Electric Co., Ltd. | | SyQuest | SyQuest Technology, Inc. | | T-MITTON | Transmitton England | | TALARIS | Talaris Systems, Inc. | | TALLGRAS | Tallgrass Technologies | | TANDBERG | Tandberg Data A/S | | TANDON | Tandon | | TEAC | TEAC Japan | | TECOLOTE | Tecolote Designs | | TEGRA | Tegra Varityper | | TENTIME | Laura Technologies, Inc. | | TI-DSG | Texas Instruments | | TOSHIBA | Toshiba Japan | | Tek | Tektronix | | ULTRA | UltraStor Corporation | | UNISYS | Unisys | | USDC | US Design Corp. | | VERBATIM | Verbatim Corporation | | VEXCEL | VEXCEL IMAGING GmbH | | VRC | Vermont Research Corp. | | WANGTEK | Wangtek | | WDIGTL | Western Digital | | WEARNES | Wearnes Technology Corporation | | WangDAT | WangDAT | | X3 | Accredited Standards Committee X3, Information Technology | | XEBEC | Xebec Corporation | +=============================================================================+ **** Unquote ***** -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Larry: Please see my response below: At 02:43 PM 4/21/96 PDT, Larry Masinter wrote: >Is the PDL naming scheme describing the device, or is it describing >the media that the device accepts? Well, let's not use the term "Media". That sounds like paper or transparencies, etc. to me. If we use "File Format" or "Format and Protocol" I will go along with that. >In this phrasing, it seems that you're describing media types rather >than devices, and that you might want to use application/postscript or >some such. That is exactly the right idea! You are pulling on the MIME methodology here, which is good, and it reflects correctly, I believe, on what we want to express, albeit not precisely enough. The Printer Working Group has chosen to be "program-specific" since it is talking about what interpreter exists in the device. I can see some need to describe the vendor, version, serial number, etc. of the exact piece of code in the device. However, that piece of code is designed around some standard or language description, and this is also needed. Perhaps an example is better here. Let's take Postscript. We have two major versions of this format/protocol, as follows: ADOBE|PS|1 ADOBE|PS|2 Ok, I am saying that ADOBE is the "Defining Body" of the specification, the specification is Postscript ("PS"), and the version is 1 or 2. These are more than just file formats since Postscript is in general also a protocol since it can involve interactive give and take. Now, we can have interpreters that are designed to use the, say, ADOBE|PS|2 language. A number of vendors may build such an animal, and in fact a given vendor may have a number of versions of this animal, each one approaching the specification to a different degree. As we all know, any english specification is insufficient to describe all the intricacies of such a protocol, and so it is nice to know what version the implementation is as well. This interpreter make and model are also defined in MFPI IS-650 using the same format. In this example, we may have say "XIONICS|4.5|F" meaning that this is a Xionics Interpreter (which may indeed be built on top of other code, such as that from Adobe), version 4.5, revision F. Although heavily related, I would hate to see us merge these into a single enum. I would hope that there is some interoperability testing among these various generations of interpreters and drivers such that they can interoperate without having too many variations on a theme introduced by the specific implementation of the language. If that is the case, there is not much use in having standards at all. The other issue here is that the "Interpreters" as specified may not be separate animals at all, but indeed, simply a subset of the capability of a larger system. Therefore, the using only the specification of the interpreter code is fraught with defects that will only continue to haunt us. You may be asking "Why be so precise -- Why not use the definitions for body types from MIME". I would be happy to be able to use the MIME types, but they are insufficient when a PDL is sent to a receiving Dial-up device for printing without user interaction. You see, MIME assumes a great deal of user interaction which we do not have the luxury of in the case of MFP's with no attached user, but still the desire to render and print the document at the dial-up site. >Larry Masinter Xerox Palo Alto Research Center (PARC) >3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333 > thanks for your comment! Regards, -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Please complete the member survey this week. I am retransmitting it in case you have forgotten. DON'T PROCRASTINATE -- DO IT NOW! DN:MFPA-96-017 MFPA 1996 MEMBER SURVEY ----------------------- Purpose: HELP CHART THE COURSE OF THE MFPA! This survey is intended to provide new direction and/or validate the current direction of the MFPA working group(s), and the attention that we give to established standards groups that are not part of the MFPA. It is understood that it is inconvenient or impossible for all member companies to attend quarterly and working group meetings that are held more often. Therefore, as a member of MFPA, please complete the following questionaire. We will then summarize the results. Your responses are strictly confidential and your company identity will not be revealed with the results of this questionaire. TimeFrame: Please consider the questions carefully and respond by Friday, 4/26/1996. -----> DUE FRIDAY, 4/26/1996 <----- Please return the questionaire promptly so that we may compile the results for the upcoming meeting 5/1-2/1996. Questionaire Method: Many of the questions below are qualitative in nature. The following scale will be used for these questions: 0 - I don't know the answer or can't rate this 1 - Poor, Way too little, Needs much improvement 2 - Fair, Slightly too little, Needs some improvement 3 - Good, About right 4 - Extra, Slightly too much, Slight reduction in Costs here 5 - Excessive, Way too much, Major reduction in Costs here 1 - TECHNICAL ============= On what should the MFPA be spending time and energy? Please indicate your interest level in each of the following technical initiatives. Use 1-5, where 1 is the highest interest, and 5 is lowest interest. 1-1) [ ] Complete MFPI-1 IS-650 as an industry standard. 1-2) [ ] Work on MFPI-2 for Fax 1-3) [ ] Work on MFPI-2 for Printing 1-4) [ ] Work on MFPI-2 for Scanning 1-5) [ ] Work on MFPI-3 1-6) [ ] Work on MFPI-4 1-7) [ ] Map MFPI-1 to SCSI 1-8) [ ] Map MFPI-1 to HP-MLC and IEEE-1284.4 1-9) [ ] Map MFPI-1 to IEEE-1394 1-10) [ ] Map MFPI-1 to USB 1-11) [ ] Transportable Document Format (TDF) and InterDomain Job Submission 1-12) [ ] Improved T.30 Protocol (Integrated with Internet) 1-13) [ ] Troika API 1-14) [ ] MFP Levels of Service and graphic designation 1-15) [ ] MFP MIB 1-16) [ ] Scanner MIB 1-17) [ ] Internal MFP interconnect standards (scanner, printer, etc.) 1-18) [ ] Harmonization with Novell NDPS and NEST 1-19) [ ] CORBA and OLE integration of services in MFP. 1-20) [ ] Fax "routing" issues 1-21) [ ] Fax Extended Negotiations Protocols (ENPs) 1-22) [ ] IS-101 related voice-modem (answering machine) stds 1-23) [ ] Simultaneous voice/data (SVD) technologies 1-24) [ ] Simultaneous voice/fax technologies 1-25) [ ] Facsimile security 1-26) [ ] MFP Operator Console standards 1-27) [ ] Phonebooks standards (Bentograms, etc) 1-28) [ ] Test Suites for MFPI, various levels 1-29) [ ] Interoperability standards for MFPI 1-30) [ ] Generation of standard VxD and sample code for MFPI-1 1-31) [ ] High-Speed facsimile 1-32) [ ] Quality conformance standards for MFPs 1-33) [ ] Enhancement of T.611 Fax API for MFPs 1-34) [ ] Enhancement of DPA for MFPs 1-35) [ ] Generation of Class-3 fax standard 1-36) [ ] BFT enhancement 1-37) [ ] BFT interoperability 1-38) [ ] Remote rendering of printed documents on MFPs, but not TDF. 1-39) [ ] Harmonization with Adobe PDF and other initiatives 1-40) [ ] TIA TR29.1, Facsimile Protocols (improved PSTN protocols, BFT) 1-41) [ ] TIA TR29.2, DTE/DCE protocols (EX: MFPI, Class1, Class2, etc.) 1-42) [ ] TIA TR30 (Data Modem Standards Committees), Generally 1-43) [ ] IEEE-1284.1, TIPSI - Transport Independent Printer Systems Interface 1-44) [ ] IEEE-1284.2, IEEE-1284 testing 1-45) [ ] IEEE-1284.3, Daisy-chain and mux enhancements for IEEE-1284 1-46) [ ] IEEE-1284.4, Standardization of HP-MLC protocol 1-47) [ ] PWG: Printer Working Group, SNMP management of printers 1-48) [ ] DMTF, Desktop Management Task Force 1-49) [ ] Salutation Consortium 1-50) [ ] Electronic Mail Association (EMA) 1-51) [ ] AIIM, Generally 1-52) [ ] AIIM, MS-53 committee standardizing compressed image formats 1-53) [ ] AIIM, MS-64 committee standardizing ISIS scanner interface 1-54) [ ] TWAIN scanner API 1-55) [ ] IETF, Internet Engineering Task Force 1-56) [ ] ICTF, Integrated Communication Architecture 1-57) [ ] IRDA, Infrared Data Assocation 1-58) [ ] USB, Universal Serial Bus 1-59) [ ] IEEE-1394 Trade Association and "FireWire" involvement 1-60) [ ] X-3 SCSI Standards committees 1-61) [ ] CORBA: Common Object Request Broker Architecture 1-62) [ ] NetWare NDPS Architecture 1-63) [ ] NetWare NEST: NetWare Embedded Systems Technology 1-64) [ ] Wordcraft Computer Fax Protocol (CFP) 1-65) [ ] Versit Computer Telephony and Personal Data Interchange 1-66) [ ] ISO-10175 Document Printing Architecture 1-67) [ ] Other: 1-68) [ ] Other: 1-69) Comments and suggestions on Techinical Initiatives: 2 - ADMINISTRATION ================== 2-1) [ ] Rate the overall amount of service provided to members (0-5). 2-2) [ ] Rate the effectiveness and quality of quarterly meetings (0-5). 2-3) [ ] Rate the effectiveness and quality of working group meetings (0-5). 2-4) Please provide your first choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-5) Please provide your second choice for meeting location: [ ] Northeast U.S. [ ] Southeast U.S. [ ] Central U.S. [ ] Northwest U.S. [ ] Southwest U.S. 2-6) [ ] Rate the meeting geographical locations selected to date. 2-7) [ ] Rate the meeting site, rooms, costs, etc. 2-8) [ ] Would you be interested in sponsoring an MFPA meeting in your area? (Y/N) 2-9) [ ] Would you support meeting charges for the attendees if the meeting is not sponsored? (perhaps $25/day) (Y/N) 2-10) [ ] Rate the membership dues for members (0-5) 2-11) [ ] Rate your involvement and participation with the MFPA NOW (0-5) 2-12) [ ] Rate your future involvement and participation with the MFPA (0-5) 2-13) Comments and Suggestions on Administration topics: 2-14) What would allow you to attend more meetings? 3 - MARKETING ============= Web Site -------- 3-1) [ ] Rate the Web Site, in general. 3-2) [ ] Should draft documents of the MFPA be in a private area of the web site? (Y/N) 3-3) Suggestions for additions to the MFPA Web Site: Tradeshows ---------- 3-4) [ ] Rate the exposure of MFPA at the COMDEX tradeshow (0-5) 3-5) [ ] Rate the exposure of MFPA at the BTA tradeshow (0-5) 3-6) Suggestions for exposure and participation at tradeshows: General ------- 3-7) Suggestions for general marketing and exposure of the MFPA: /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Larry: Please see my response below: At 02:43 PM 4/21/96 PDT, Larry Masinter wrote: >Is the PDL naming scheme describing the device, or is it describing >the media that the device accepts? Well, let's not use the term "Media". That sounds like paper or transparencies, etc. to me. If we use "File Format" or "Format and Protocol" I will go along with that. >In this phrasing, it seems that you're describing media types rather >than devices, and that you might want to use application/postscript or >some such. That is exactly the right idea! You are pulling on the MIME methodology here, which is good, and it reflects correctly, I believe, on what we want to express, albeit not precisely enough. The Printer Working Group has chosen to be "program-specific" since it is talking about what interpreter exists in the device. I can see some need to describe the vendor, version, serial number, etc. of the exact piece of code in the device. However, that piece of code is designed around some standard or language description, and this is also needed. Perhaps an example is better here. Let's take Postscript. We have two major versions of this format/protocol, as follows: ADOBE|PS|1 ADOBE|PS|2 Ok, I am saying that ADOBE is the "Defining Body" of the specification, the specification is Postscript ("PS"), and the version is 1 or 2. These are more than just file formats since Postscript is in general also a protocol since it can involve interactive give and take. Now, we can have interpreters that are designed to use the, say, ADOBE|PS|2 language. A number of vendors may build such an animal, and in fact a given vendor may have a number of versions of this animal, each one approaching the specification to a different degree. As we all know, any english specification is insufficient to describe all the intricacies of such a protocol, and so it is nice to know what version the implementation is as well. This interpreter make and model are also defined in MFPI IS-650 using the same format. In this example, we may have say "XIONICS|4.5|F" meaning that this is a Xionics Interpreter (which may indeed be built on top of other code, such as that from Adobe), version 4.5, revision F. Although heavily related, I would hate to see us merge these into a single enum. I would hope that there is some interoperability testing among these various generations of interpreters and drivers such that they can interoperate without having too many variations on a theme introduced by the specific implementation of the language. If that is the case, there is not much use in having standards at all. The other issue here is that the "Interpreters" as specified may not be separate animals at all, but indeed, simply a subset of the capability of a larger system. Therefore, the using only the specification of the interpreter code is fraught with defects that will only continue to haunt us. You may be asking "Why be so precise -- Why not use the definitions for body types from MIME". I would be happy to be able to use the MIME types, but they are insufficient when a PDL is sent to a receiving Dial-up device for printing without user interaction. You see, MIME assumes a great deal of user interaction which we do not have the luxury of in the case of MFP's with no attached user, but still the desire to render and print the document at the dial-up site. >Larry Masinter Xerox Palo Alto Research Center (PARC) >3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333 > thanks for your comment! Regards, -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Ray Lutz wrote (excerpts) ... > The owner or company is meant as the owner of the remaining definition. > For most applications, the will be formatted as > > Defining_Body|Model|Version|Serial_Number > >The "languageId" uses this form and are listed in ANNEX C. > >To give you an idea of the company names already defined by SCSI, I have >reproduced this list below. This is an extraction from the SCSI-3 "SPC" draft. > >| PRIAM | Priam | >| PRIMAGFX | Primagraphics Ltd | >| PTI | Peripheral Technology Inc. | >| QIC | Quarter-Inch Cartridge Drive Standards, Inc. | Ray - would there be any value in assigning the PWG as the defining_body? This would point directly to the Printer MIB definitions. As far as Version (level), it is the intent of all PWG participants to follow industry accepted norms for this attribute. So, if 5e is a well known version of PCL, there is nothing to stop a printer manufacturer from calling it "five eeeee", but there is absolutely no motivation to do so. I think the one-to-one mapping is possible in a very pragmatic sense. PWG has not discussed this, but if we need more control, I believe an appendix of recommended prtInterpreterLangFamily (enum) and prtInterpreterLangLevel (string) associations should be possible. We have a similar appendix for media sizes and names. >Perhaps an example is better here. Let's take Postscript. We have two major >versions of this format/protocol, as follows: > > ADOBE|PS|1 > ADOBE|PS|2 > >Ok, I am saying that ADOBE is the "Defining Body" of the specification, the >specification is Postscript ("PS"), and the version is 1 or 2. These are > >This interpreter make and model are also defined in MFPI IS-650 using the >same format. In this example, we may have say "XIONICS|4.5|F" >meaning that this is a Xionics Interpreter (which may indeed be built on top >of other code, such as that from Adobe), version 4.5, revision F. Ray, now I'm confused. Using your PS example, I would interpret your XIONICS example as follows. Defining Body - XIONICS Language ------ 4.5 Version ------- F >Perhaps an example is better here. Let's take Postscript. We have two major >versions of this format/protocol, as follows: > > ADOBE|PS|1 > ADOBE|PS|2 > >Ok, I am saying that ADOBE is the "Defining Body" of the specification, the >specification is Postscript ("PS"), and the version is 1 or 2. These are > >This interpreter make and model are also defined in MFPI IS-650 using the >same format. In this example, we may have say "XIONICS|4.5|F" >meaning that this is a Xionics Interpreter (which may indeed be built on top >of other code, such as that from Adobe), version 4.5, revision F. Ray, now I'm confused. Using your PS example, I would interpret your XIONICS example as follows. Defining Body - XIONICS Language ------ 4.5 Version ------- F Ray Lutz wrote (excerpts) ... > The owner or company is meant as the owner of the remaining definition. > For most applications, the will be formatted as > > Defining_Body|Model|Version|Serial_Number > >The "languageId" uses this form and are listed in ANNEX C. > >To give you an idea of the company names already defined by SCSI, I have >reproduced this list below. This is an extraction from the SCSI-3 "SPC" draft. > >| PRIAM | Priam | >| PRIMAGFX | Primagraphics Ltd | >| PTI | Peripheral Technology Inc. | >| QIC | Quarter-Inch Cartridge Drive Standards, Inc. | Ray - would there be any value in assigning the PWG as the defining_body? This would point directly to the Printer MIB definitions. As far as Version (level), it is the intent of all PWG participants to follow industry accepted norms for this attribute. So, if 5e is a well known version of PCL, there is nothing to stop a printer manufacturer from calling it "five eeeee", but there is absolutely no motivation to do so. I think the one-to-one mapping is possible in a very pragmatic sense. PWG has not discussed this, but if we need more control, I believe an appendix of recommended prtInterpreterLangFamily (enum) and prtInterpreterLangLevel (string) associations should be possible. We have a similar appendix for media sizes and names. Ray Lutz wrote (excerpts) ... > The owner or company is meant as the owner of the remaining definition. > For most applications, the will be formatted as > > Defining_Body|Model|Version|Serial_Number > >The "languageId" uses this form and are listed in ANNEX C. > >To give you an idea of the company names already defined by SCSI, I have >reproduced this list below. This is an extraction from the SCSI-3 "SPC" draft. > >| PRIAM | Priam | >| PRIMAGFX | Primagraphics Ltd | >| PTI | Peripheral Technology Inc. | >| QIC | Quarter-Inch Cartridge Drive Standards, Inc. | Ray - would there be any value in assigning the PWG as the defining_body? This would point directly to the Printer MIB definitions. As far as Version (level), it is the intent of all PWG participants to follow industry accepted norms for this attribute. So, if 5e is a well known version of PCL, there is nothing to stop a printer manufacturer from calling it "five eeeee", but there is absolutely no motivation to do so. I think the one-to-one mapping is possible in a very pragmatic sense. PWG has not discussed this, but if we need more control, I believe an appendix of recommended prtInterpreterLangFamily (enum) and prtInterpreterLangLevel (string) associations should be possible. We have a similar appendix for media sizes and names. >Perhaps an example is better here. Let's take Postscript. We have two major >versions of this format/protocol, as follows: > > ADOBE|PS|1 > ADOBE|PS|2 > >Ok, I am saying that ADOBE is the "Defining Body" of the specification, the >specification is Postscript ("PS"), and the version is 1 or 2. These are > >This interpreter make and model are also defined in MFPI IS-650 using the >same format. In this example, we may have say "XIONICS|4.5|F" >meaning that this is a Xionics Interpreter (which may indeed be built on top >of other code, such as that from Adobe), version 4.5, revision F. Ray, now I'm confused. Using your PS example, I would interpret your XIONICS example as follows. Defining Body - XIONICS Language ------ 4.5 Version ------- F Harry: Regarding your question: ... >would there be any value in assigning the PWG as the defining_body? Well, it is, but it is not "sanctioned". So far, IETF and DMTF are the defining bodies. PWG is just a working group. I think you have to be in existence for at least 5 years or something to get even OID defining capability. >This would point directly to the Printer MIB definitions. As far as >Version (level), it is the intent of all PWG participants to follow industry >accepted norms for this attribute. So, if 5e is a well known version of >PCL, there is nothing to stop a printer manufacturer from calling it >"five eeeee", but there is absolutely no motivation to do so. I think the >one-to-one mapping is possible in a very pragmatic sense. PWG has not >discussed this, but if we need more control, I believe an appendix of >recommended prtInterpreterLangFamily (enum) and prtInterpreterLangLevel >(string) associations should be possible. We have a similar appendix for >media sizes and names. I think that refining the Printer MIB PrtInterpreterLang... is doable and reasonable. All we have to do is to do it. So, let's say that the PWG does this refinement. Now, the next question is, can it be used in a general sense (for applications other than Management Station use)? So far, the answer is no. Why? Well, it is because of the table nature of the definition and the fact that there is a lot of stuff in the table others are not interested in. So, if we can't get the entire definition into a single object, I don't want to see others use it. This is why OIDs are defined as a single object. You may note that the DMTF uses the same "DMTF|MIF|1.0" type of definition for MIF's. Also, the structure is similar to OBJECT ID structure. So, IS-650 and DMTF are in harmony. IS-650 and ASN.1 OBJECT IDENTIFIERS are in harmony. Please note: we can refer to the PWG enum as follows: "IETF|RFC-1759||| " The stuff in <> I am not sure of the exact number. For PCL-3 it would be: "IETF|RFC-1759||3|" This is all just a guess. If you can pin it down, we will consider it as an alternative, but I just think: HP|PCL|3 Is a lot simpler and easier in case the user does not happen to have the RFC-1759 document. He will need the PCL document from HP if he wants to send this device control information anyway. *********** PROPOSAL: I would like to propose that the printer working group consider a scheme as I have outlined, and is in use by DMTF and IS-650. This would be an additional entry in the PrtInterpreterLangTable, would have a STRING data type, and would be controlled by IETF. The ones of interest to me are: HP|PCL|3 HP|PCL|4 HP|PCL|5 HP|PCL|5E ADOBE|PS|1 ADOBE|PS|2 ???|GDI|??? ********** What do you think? -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Harry: referencing your question below, don't get tied up with the terminology of each piece of the string. Once a defining body has been determined, it is up to that group to determine the other strings. For a piece of equipment, such as a software module, the terms "make" and "model" are more appropriate than Language oriented terms. Make: XIONICS Model: 4.5 (Up to Xionics to define) Version: F (Up to Xionics to define) Serial Number: 9287984371508741 We have "XIONICS|4.5|F|9287984371508741" This is the "recipe" method of defining a name. You start with the most general and refine with each substring. See DMTF MIF for their definition of the MIF format string. >>This interpreter make and model are also defined in MFPI IS-650 using the >>same format. In this example, we may have say "XIONICS|4.5|F" >>meaning that this is a Xionics Interpreter (which may indeed be built on top >>of other code, such as that from Adobe), version 4.5, revision F. > >Ray, now I'm confused. Using your PS example, I would interpret your >XIONICS example as follows. > >Defining Body - XIONICS >Language ------ 4.5 >Version ------- F > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Harry: Regarding your question: ... >would there be any value in assigning the PWG as the defining_body? Well, it is, but it is not "sanctioned". So far, IETF and DMTF are the defining bodies. PWG is just a working group. I think you have to be in existence for at least 5 years or something to get even OID defining capability. >This would point directly to the Printer MIB definitions. As far as >Version (level), it is the intent of all PWG participants to follow industry >accepted norms for this attribute. So, if 5e is a well known version of >PCL, there is nothing to stop a printer manufacturer from calling it >"five eeeee", but there is absolutely no motivation to do so. I think the >one-to-one mapping is possible in a very pragmatic sense. PWG has not >discussed this, but if we need more control, I believe an appendix of >recommended prtInterpreterLangFamily (enum) and prtInterpreterLangLevel >(string) associations should be possible. We have a similar appendix for >media sizes and names. I think that refining the Printer MIB PrtInterpreterLang... is doable and reasonable. All we have to do is to do it. So, let's say that the PWG does this refinement. Now, the next question is, can it be used in a general sense (for applications other than Management Station use)? So far, the answer is no. Why? Well, it is because of the table nature of the definition and the fact that there is a lot of stuff in the table others are not interested in. So, if we can't get the entire definition into a single object, I don't want to see others use it. This is why OIDs are defined as a single object. You may note that the DMTF uses the same "DMTF|MIF|1.0" type of definition for MIF's. Also, the structure is similar to OBJECT ID structure. So, IS-650 and DMTF are in harmony. IS-650 and ASN.1 OBJECT IDENTIFIERS are in harmony. Please note: we can refer to the PWG enum as follows: "IETF|RFC-1759||| " The stuff in <> I am not sure of the exact number. For PCL-3 it would be: "IETF|RFC-1759||3|" This is all just a guess. If you can pin it down, we will consider it as an alternative, but I just think: HP|PCL|3 Is a lot simpler and easier in case the user does not happen to have the RFC-1759 document. He will need the PCL document from HP if he wants to send this device control information anyway. *********** PROPOSAL: I would like to propose that the printer working group consider a scheme as I have outlined, and is in use by DMTF and IS-650. This would be an additional entry in the PrtInterpreterLangTable, would have a STRING data type, and would be controlled by IETF. The ones of interest to me are: HP|PCL|3 HP|PCL|4 HP|PCL|5 HP|PCL|5E ADOBE|PS|1 ADOBE|PS|2 ???|GDI|??? ********** What do you think? -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Harry: referencing your question below, don't get tied up with the terminology of each piece of the string. Once a defining body has been determined, it is up to that group to determine the other strings. For a piece of equipment, such as a software module, the terms "make" and "model" are more appropriate than Language oriented terms. Make: XIONICS Model: 4.5 (Up to Xionics to define) Version: F (Up to Xionics to define) Serial Number: 9287984371508741 We have "XIONICS|4.5|F|9287984371508741" This is the "recipe" method of defining a name. You start with the most general and refine with each substring. See DMTF MIF for their definition of the MIF format string. >>This interpreter make and model are also defined in MFPI IS-650 using the >>same format. In this example, we may have say "XIONICS|4.5|F" >>meaning that this is a Xionics Interpreter (which may indeed be built on top >>of other code, such as that from Adobe), version 4.5, revision F. > >Ray, now I'm confused. Using your PS example, I would interpret your >XIONICS example as follows. > >Defining Body - XIONICS >Language ------ 4.5 >Version ------- F > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Correct me, but I believe many of our industries associated standards groups have been in existence less than 5 years (DMTF, Salutation, MFPA). Some make ties with other standards orgs as MFPA, NPA and PWG have done in the past, some, like DMTF and Salutation do not. The main distinction I see is that PWG doesn't carry dues or charge for specs and such. It's just a different approach. What defines sanctioned? Expected longevity? That's real tricky. Does collecting money make it more official? > Well, it is, but it is not "sanctioned". So far, IETF and DMTF are the > defining bodies. PWG is just a working group. I think you have to be in > existence for at least 5 years or something to get even OID defining > capability. Correct me, but I believe many of our industries associated standards groups have been in existence less than 5 years (DMTF, Salutation, MFPA). Some make ties with other standards orgs as MFPA, NPA and PWG have done in the past, some, like DMTF and Salutation do not. The main distinction I see is that PWG doesn't carry dues or charge for specs and such. It's just a different approach. What defines sanctioned? Expected longevity? That's real tricky. Does collecting money make it more official? > Well, it is, but it is not "sanctioned". So far, IETF and DMTF are the > defining bodies. PWG is just a working group. I think you have to be in > existence for at least 5 years or something to get even OID defining > capability. Correct me, but I believe many of our industries associated standards groups have been in existence less than 5 years (DMTF, Salutation, MFPA). Some make ties with other standards orgs as MFPA, NPA and PWG have done in the past, some, like DMTF and Salutation do not. The main distinction I see is that PWG doesn't carry dues or charge for specs and such. It's just a different approach. What defines sanctioned? Expected longevity? That's real tricky. Does collecting money make it more official? > Well, it is, but it is not "sanctioned". So far, IETF and DMTF are the > defining bodies. PWG is just a working group. I think you have to be in > existence for at least 5 years or something to get even OID defining > capability. Ray Lutz wrote... >I would like to propose that the printer working group consider a scheme as >I have outlined, and is in use by DMTF and IS-650. This would be an >additional entry in the PrtInterpreterLangTable, would have a STRING data >type, and would be controlled by IETF. The ones of interest to me are: > > HP|PCL|3 > HP|PCL|4 > HP|PCL|5 > HP|PCL|5E > ADOBE|PS|1 > ADOBE|PS|2 > ???|GDI|??? Ray, as you'll see in our minutes, we discussed this proposal at the April PWG meeting and came to the conclusion that prtInterpreterLangLevel should map directly to "version" in you scheme. I was trying to indicate this when I began this thread. Since the PWG does not have access to the complete IS-650 spec, we were unaware of your overall generalized scheme. We felt that your LANG specific proposal (||), mapped well to the Printer MIB except for "owner". As such, PDL name is enumerated in prtInterpreterLangFamily and "version" is contained in prtInterpreterLangLevel. I took liberty, during this thread, to further propose some loose control on LangLevel strings that I feel the PWG might go along with: Loose syntax example... MFPA RFC1759 HP|PCL|5e langPCL (3), langLevel "5e" ADOBE|PS|2 langPS (6), langLevel "2" We could carry this a step further and come up with MFPA registration of PWG|3|5e PWG|6|2 That's all I was suggesting when I mentioned "PWG" as an "owner". Ray Lutz wrote... >I would like to propose that the printer working group consider a scheme as >I have outlined, and is in use by DMTF and IS-650. This would be an >additional entry in the PrtInterpreterLangTable, would have a STRING data >type, and would be controlled by IETF. The ones of interest to me are: > > HP|PCL|3 > HP|PCL|4 > HP|PCL|5 > HP|PCL|5E > ADOBE|PS|1 > ADOBE|PS|2 > ???|GDI|??? Ray, as you'll see in our minutes, we discussed this proposal at the April PWG meeting and came to the conclusion that prtInterpreterLangLevel should map directly to "version" in you scheme. I was trying to indicate this when I began this thread. Since the PWG does not have access to the complete IS-650 spec, we were unaware of your overall generalized scheme. We felt that your LANG specific proposal (||), mapped well to the Printer MIB except for "owner". As such, PDL name is enumerated in prtInterpreterLangFamily and "version" is contained in prtInterpreterLangLevel. I took liberty, during this thread, to further propose some loose control on LangLevel strings that I feel the PWG might go along with: Loose syntax example... MFPA RFC1759 HP|PCL|5e langPCL (3), langLevel "5e" ADOBE|PS|2 langPS (6), langLevel "2" We could carry this a step further and come up with MFPA registration of PWG|3|5e PWG|6|2 That's all I was suggesting when I mentioned "PWG" as an "owner". Ray Lutz wrote... >I would like to propose that the printer working group consider a scheme as >I have outlined, and is in use by DMTF and IS-650. This would be an >additional entry in the PrtInterpreterLangTable, would have a STRING data >type, and would be controlled by IETF. The ones of interest to me are: > > HP|PCL|3 > HP|PCL|4 > HP|PCL|5 > HP|PCL|5E > ADOBE|PS|1 > ADOBE|PS|2 > ???|GDI|??? Ray, as you'll see in our minutes, we discussed this proposal at the April PWG meeting and came to the conclusion that prtInterpreterLangLevel should map directly to "version" in you scheme. I was trying to indicate this when I began this thread. Since the PWG does not have access to the complete IS-650 spec, we were unaware of your overall generalized scheme. We felt that your LANG specific proposal (||), mapped well to the Printer MIB except for "owner". As such, PDL name is enumerated in prtInterpreterLangFamily and "version" is contained in prtInterpreterLangLevel. I took liberty, during this thread, to further propose some loose control on LangLevel strings that I feel the PWG might go along with: Loose syntax example... MFPA RFC1759 HP|PCL|5e langPCL (3), langLevel "5e" ADOBE|PS|2 langPS (6), langLevel "2" We could carry this a step further and come up with MFPA registration of PWG|3|5e PWG|6|2 That's all I was suggesting when I mentioned "PWG" as an "owner". Harry, see my other message to Jay also... >What defines sanctioned? An important question. And, I must admit, this is one that I asked also a while back in the effort to get MFP work rolling. In a nutshell, sanctioned generally means that you have a set of operating procedures and rules that have been examined by an outside group for fairness and such that the good of the public is maintained. ANSI is such a body in the US. If you are large enough, you can force your own standards without such sanctions (IEEE, IETF, etc.), although to get the ANSI seal of approval, you have to have rules that meet their requirements. If you can become sanctioned and pay the attorneys fees somehow without collecting membership dues or selling your standards documents, then you will be inventing a new wheel. However, I consider that a rat hole with no cheese at the end. If you want cheese, I suggest one of two things: 1) Copy an existing successful business plan. 2) Become part of someone else's successful business plan. Right now, PWG has a lot of good technical expertise and has and is doing good technical work. I certainly don't want to denegrate that. However, the PWG is running on empty when it comes to a reasonable business plan that may work in the long term. Are there any bylaws or procedure documents prepared? Not that I know of. Will the mission statement and business plan become real and actually assist the PWG's work vs. being a terrible sink of good technical expertise on business issues? I just don't know how you can do it without some influx of money. Honestly, I believe that the best course of action is for the PWG to get under the umbrella of another sanctioned group, at least as far as progressing standards is concerned. I think the establishment of a separate entity is just not real. Will this damage the spirit of the PWG? Maybe a little. The PWG topic is important, but will become just one of many that the larger organization is working on. Other than that, you can probably operate much as you do now. Even if you are "sanctioned" there is going to be some overlap and replication of work with other groups, no matter how hard you try. Not everyone will use the enums that you establish. This is a mixed curse, since sometimes those sort of challenges is how the best ideas surface. -Raymond Harry: Perhaps it would be a good idea to present this idea again to the PWG with additional information. IS-650 is a published document which is available from Global Engineering Documents. I think I have made the case clear as to why these organizations charge for their documents. It is not something I like, but I accept it as a fact of doing business. As an interim standard it is undergoing new changes which are not available to the public at large, but the relevant section really has not changed at all. The nice part about using the strings that I have mentioned is that it actually references the standard or specification document, not just the RFC-1759 which then lists the standards document. I don't have any trouble with the idea of mapping the "prtInterpreterLangVersion" to the Version field of the IS-650 spec. However, the idea of referring to RFC-1759 as the spec does little good. All you are doing is enumerating them. I need to know the gory details. The question is who is the owner of the gory details? This is the owner. Anyone can make a list. I need to know the real owner. Therefore, I don't agree with your proposal to make PWG the owner. NOW, who is the owner of RFC-1759? Not PWG. It is EITF. So, this would be: "IETF|RFC-1759|1" If we assume it is version 1. I don't think a working group should be the owner of anything. Working groups are disbanded and their members disperse over time. We were talking about an additional single entry in the table before, I am only trying to improve on the suggestion that has already been agreed to for several meetings. So far, it is an integer. I propose that it be a string so that it is in harmony with DMTF (your recent umbrella). This DOES NOT corrupt the enum scheme that you are using, but simply augments it by collecting the owner and other components as one string, and therefore one object. -Raymond At 03:51 PM 4/22/96 MDT, Harry Lewis wrote: >Ray Lutz wrote... > >>I would like to propose that the printer working group consider a scheme as >>I have outlined, and is in use by DMTF and IS-650. This would be an >>additional entry in the PrtInterpreterLangTable, would have a STRING data >>type, and would be controlled by IETF. The ones of interest to me are: >> >> HP|PCL|3 >> HP|PCL|4 >> HP|PCL|5 >> HP|PCL|5E >> ADOBE|PS|1 >> ADOBE|PS|2 >> ???|GDI|??? > >Ray, as you'll see in our minutes, we discussed this proposal at the >April PWG meeting and came to the conclusion that prtInterpreterLangLevel >should map directly to "version" in you scheme. I was trying to indicate this >when I began this thread. > >Since the PWG does not have access to the complete IS-650 spec, we were >unaware of your overall generalized scheme. We felt that your LANG >specific proposal (||), mapped well to the >Printer MIB except for "owner". As such, PDL name is enumerated in >prtInterpreterLangFamily and "version" is contained in >prtInterpreterLangLevel. I took liberty, during this thread, to further >propose some loose control on LangLevel strings that I feel the PWG might >go along with: > >Loose syntax example... > > MFPA RFC1759 > > HP|PCL|5e langPCL (3), langLevel "5e" > ADOBE|PS|2 langPS (6), langLevel "2" > >We could carry this a step further and come up with MFPA registration of > > PWG|3|5e > PWG|6|2 > >That's all I was suggesting when I mentioned "PWG" as an "owner". > > > Harry: Perhaps it would be a good idea to present this idea again to the PWG with additional information. IS-650 is a published document which is available from Global Engineering Documents. I think I have made the case clear as to why these organizations charge for their documents. It is not something I like, but I accept it as a fact of doing business. As an interim standard it is undergoing new changes which are not available to the public at large, but the relevant section really has not changed at all. The nice part about using the strings that I have mentioned is that it actually references the standard or specification document, not just the RFC-1759 which then lists the standards document. I don't have any trouble with the idea of mapping the "prtInterpreterLangVersion" to the Version field of the IS-650 spec. However, the idea of referring to RFC-1759 as the spec does little good. All you are doing is enumerating them. I need to know the gory details. The question is who is the owner of the gory details? This is the owner. Anyone can make a list. I need to know the real owner. Therefore, I don't agree with your proposal to make PWG the owner. NOW, who is the owner of RFC-1759? Not PWG. It is EITF. So, this would be: "IETF|RFC-1759|1" If we assume it is version 1. I don't think a working group should be the owner of anything. Working groups are disbanded and their members disperse over time. We were talking about an additional single entry in the table before, I am only trying to improve on the suggestion that has already been agreed to for several meetings. So far, it is an integer. I propose that it be a string so that it is in harmony with DMTF (your recent umbrella). This DOES NOT corrupt the enum scheme that you are using, but simply augments it by collecting the owner and other components as one string, and therefore one object. -Raymond At 03:51 PM 4/22/96 MDT, Harry Lewis wrote: >Ray Lutz wrote... > >>I would like to propose that the printer working group consider a scheme as >>I have outlined, and is in use by DMTF and IS-650. This would be an >>additional entry in the PrtInterpreterLangTable, would have a STRING data >>type, and would be controlled by IETF. The ones of interest to me are: >> >> HP|PCL|3 >> HP|PCL|4 >> HP|PCL|5 >> HP|PCL|5E >> ADOBE|PS|1 >> ADOBE|PS|2 >> ???|GDI|??? > >Ray, as you'll see in our minutes, we discussed this proposal at the >April PWG meeting and came to the conclusion that prtInterpreterLangLevel >should map directly to "version" in you scheme. I was trying to indicate this >when I began this thread. > >Since the PWG does not have access to the complete IS-650 spec, we were >unaware of your overall generalized scheme. We felt that your LANG >specific proposal (||), mapped well to the >Printer MIB except for "owner". As such, PDL name is enumerated in >prtInterpreterLangFamily and "version" is contained in >prtInterpreterLangLevel. I took liberty, during this thread, to further >propose some loose control on LangLevel strings that I feel the PWG might >go along with: > >Loose syntax example... > > MFPA RFC1759 > > HP|PCL|5e langPCL (3), langLevel "5e" > ADOBE|PS|2 langPS (6), langLevel "2" > >We could carry this a step further and come up with MFPA registration of > > PWG|3|5e > PWG|6|2 > >That's all I was suggesting when I mentioned "PWG" as an "owner". > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Harry, see my other message to Jay also... >What defines sanctioned? An important question. And, I must admit, this is one that I asked also a while back in the effort to get MFP work rolling. In a nutshell, sanctioned generally means that you have a set of operating procedures and rules that have been examined by an outside group for fairness and such that the good of the public is maintained. ANSI is such a body in the US. If you are large enough, you can force your own standards without such sanctions (IEEE, IETF, etc.), although to get the ANSI seal of approval, you have to have rules that meet their requirements. If you can become sanctioned and pay the attorneys fees somehow without collecting membership dues or selling your standards documents, then you will be inventing a new wheel. However, I consider that a rat hole with no cheese at the end. If you want cheese, I suggest one of two things: 1) Copy an existing successful business plan. 2) Become part of someone else's successful business plan. Right now, PWG has a lot of good technical expertise and has and is doing good technical work. I certainly don't want to denegrate that. However, the PWG is running on empty when it comes to a reasonable business plan that may work in the long term. Are there any bylaws or procedure documents prepared? Not that I know of. Will the mission statement and business plan become real and actually assist the PWG's work vs. being a terrible sink of good technical expertise on business issues? I just don't know how you can do it without some influx of money. Honestly, I believe that the best course of action is for the PWG to get under the umbrella of another sanctioned group, at least as far as progressing standards is concerned. I think the establishment of a separate entity is just not real. Will this damage the spirit of the PWG? Maybe a little. The PWG topic is important, but will become just one of many that the larger organization is working on. Other than that, you can probably operate much as you do now. Even if you are "sanctioned" there is going to be some overlap and replication of work with other groups, no matter how hard you try. Not everyone will use the enums that you establish. This is a mixed curse, since sometimes those sort of challenges is how the best ideas surface. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Harry, see my other message to Jay also... >What defines sanctioned? An important question. And, I must admit, this is one that I asked also a while back in the effort to get MFP work rolling. In a nutshell, sanctioned generally means that you have a set of operating procedures and rules that have been examined by an outside group for fairness and such that the good of the public is maintained. ANSI is such a body in the US. If you are large enough, you can force your own standards without such sanctions (IEEE, IETF, etc.), although to get the ANSI seal of approval, you have to have rules that meet their requirements. If you can become sanctioned and pay the attorneys fees somehow without collecting membership dues or selling your standards documents, then you will be inventing a new wheel. However, I consider that a rat hole with no cheese at the end. If you want cheese, I suggest one of two things: 1) Copy an existing successful business plan. 2) Become part of someone else's successful business plan. Right now, PWG has a lot of good technical expertise and has and is doing good technical work. I certainly don't want to denegrate that. However, the PWG is running on empty when it comes to a reasonable business plan that may work in the long term. Are there any bylaws or procedure documents prepared? Not that I know of. Will the mission statement and business plan become real and actually assist the PWG's work vs. being a terrible sink of good technical expertise on business issues? I just don't know how you can do it without some influx of money. Honestly, I believe that the best course of action is for the PWG to get under the umbrella of another sanctioned group, at least as far as progressing standards is concerned. I think the establishment of a separate entity is just not real. Will this damage the spirit of the PWG? Maybe a little. The PWG topic is important, but will become just one of many that the larger organization is working on. Other than that, you can probably operate much as you do now. Even if you are "sanctioned" there is going to be some overlap and replication of work with other groups, no matter how hard you try. Not everyone will use the enums that you establish. This is a mixed curse, since sometimes those sort of challenges is how the best ideas surface. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Harry: Perhaps it would be a good idea to present this idea again to the PWG with additional information. IS-650 is a published document which is available from Global Engineering Documents. I think I have made the case clear as to why these organizations charge for their documents. It is not something I like, but I accept it as a fact of doing business. As an interim standard it is undergoing new changes which are not available to the public at large, but the relevant section really has not changed at all. The nice part about using the strings that I have mentioned is that it actually references the standard or specification document, not just the RFC-1759 which then lists the standards document. I don't have any trouble with the idea of mapping the "prtInterpreterLangVersion" to the Version field of the IS-650 spec. However, the idea of referring to RFC-1759 as the spec does little good. All you are doing is enumerating them. I need to know the gory details. The question is who is the owner of the gory details? This is the owner. Anyone can make a list. I need to know the real owner. Therefore, I don't agree with your proposal to make PWG the owner. NOW, who is the owner of RFC-1759? Not PWG. It is EITF. So, this would be: "IETF|RFC-1759|1" If we assume it is version 1. I don't think a working group should be the owner of anything. Working groups are disbanded and their members disperse over time. We were talking about an additional single entry in the table before, I am only trying to improve on the suggestion that has already been agreed to for several meetings. So far, it is an integer. I propose that it be a string so that it is in harmony with DMTF (your recent umbrella). This DOES NOT corrupt the enum scheme that you are using, but simply augments it by collecting the owner and other components as one string, and therefore one object. -Raymond At 03:51 PM 4/22/96 MDT, Harry Lewis wrote: >Ray Lutz wrote... > >>I would like to propose that the printer working group consider a scheme as >>I have outlined, and is in use by DMTF and IS-650. This would be an >>additional entry in the PrtInterpreterLangTable, would have a STRING data >>type, and would be controlled by IETF. The ones of interest to me are: >> >> HP|PCL|3 >> HP|PCL|4 >> HP|PCL|5 >> HP|PCL|5E >> ADOBE|PS|1 >> ADOBE|PS|2 >> ???|GDI|??? > >Ray, as you'll see in our minutes, we discussed this proposal at the >April PWG meeting and came to the conclusion that prtInterpreterLangLevel >should map directly to "version" in you scheme. I was trying to indicate this >when I began this thread. > >Since the PWG does not have access to the complete IS-650 spec, we were >unaware of your overall generalized scheme. We felt that your LANG >specific proposal (||), mapped well to the >Printer MIB except for "owner". As such, PDL name is enumerated in >prtInterpreterLangFamily and "version" is contained in >prtInterpreterLangLevel. I took liberty, during this thread, to further >propose some loose control on LangLevel strings that I feel the PWG might >go along with: > >Loose syntax example... > > MFPA RFC1759 > > HP|PCL|5e langPCL (3), langLevel "5e" > ADOBE|PS|2 langPS (6), langLevel "2" > >We could carry this a step further and come up with MFPA registration of > > PWG|3|5e > PWG|6|2 > >That's all I was suggesting when I mentioned "PWG" as an "owner". > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Jay... At 10:37 PM 4/22/96 EDT, JK Martin wrote: >Ray, > >> If you want to remain relatively independent, I can't blame you. MFPA has >> found that we need to be involved in many overlapping standards groups, and >> this was the primary impetus behind remaining somewhat independent, although >> we run our standards strictly through accredited standards bodies, whenever >> possible, such as TIA, IEEE, AIIM, etc. > >Why didn't the MFPA find "shelter" under one of the "umbrella" organizations? >I find this most interesting, indeed. We have from the start. We work closely with TIA and the facsimile standards committee. I am the Vice Chair of TIA TR29.2. Fax is the most standards-sensitive part of an MFP. However, the fax folks don't like to get involved in printer-only or scanner-only stuff. Meanwhile, printer groups and scanner groups could care less about fax stuff, or for that matter, printer groups don't care about scanner stuff. Imagine if you would, a person coming to the printer working group with a proposal to work on the Scanner MIB, of maybe the Fax MIB. Would it fly? I doubt it. As it is, there is a bunch of printer stuff (finishing) that was subtracted from the purview of the PWG and sent to the LMO group. As it is, I have had a hard time getting much support for the PWG to work on printer-oriented work that is just slightly off the train of thought of the PWG. The MFPA is not trying to be a sanctioned standards body. We are a trade association, albeit technically oriented and with an agenda to get the MFP-oriented standards pushed through the various committees. My suggestion below is that I think a real (more general) PWG is quite synergistic with the agenda of the MFPA. However, reality is reality, and the PWG is a nice collection of companies working on printers from one angle or another. And your current focus is useful, but I am afraid that the printer MIB is perhaps already too printer centric to be easily extended to MFP use. A good related question to ask is "When do competitive companies work together?". The answer is simple, "Only when absolutely necessary". My friend, Ken Krechmer of ACTION Consulting has a good quote: "Communication requires standards and standards require communication." He makes the point that standards are only needed when products or things must communicate. These agreements allow everything to work together more easily. In this age of communication, standards have become very important. It turns out that MFP's involve communications and therefore standards are indeed important. >> Certainly MFPA is willing to work with you on any creative ideas. Since the >> printer is a major portion of the MFP device, a printer standards groups >> seems reasonable. However, the PWG is not really a Printer WG, but a >> "Distributed Printer Management WG"; very specific albeit important at the >> moment. The PWG's mission statement is perhaps the first place to start to >> get an understanding of the wishes of the group. > >Hmmm. PWG has too narrow a focus? I wonder what others think about this, >particularly when compared to the MFPA. MFPA is involved in many standards bodies. We have a large focus because an MFP contains many devices, printers, scanners, facsimile, finishing, data modem, voice answering devices, etc. etc. Granted, you have to have some sort of focus or you will be too general. Our focus is at a different "plane", somewhat more market oriented. >For fear of appearing to be "PWG vs. MFPA" (which is NOT what I intend, >I assure you), it just seems strange to me that the MFPA would seek >independent organizational status, but that (in your opinion) the PWG >should not. You misunderstand. MFPA **IS NOT** a standards body and **IS NOT** sanctioned. We take the adoptee role with TIA, AIIM, IEEE, etc. However, we exist as a trade association with bylaws and other organizational documents and when necessary we will create and promote marketing and technical specifications. Printer standards groups already exist. However, there is little impetus to printer people cooperating since there is little "communication". If you succumb to the domination of the major (unnamed, but look at the list for MFPs) printer languages, then most of the printer communication and protocol has been completed, and there is little work to do. Certainly standards-based printer languages were tried, and many companies tried to hang their hat on these. Too bad that TIPSI (NPAP) was so printer centric, or there would be more interest in it by MFPA and the MFP industry. So I am happy to see the printer companies working together on printer management. As you may remember, printer management, and network management in general was a horrible problem until the recent improvements. And there is still work to be done. But the larger scope here is "Network Device Management". PWG does not have this broad scope. To narrow it to network Printer management means that the group will ignore all other sort of devices, this is not a good solution. >Perhaps the sheer numbers of printers currently installed is not >relevant in this topic, but it would seem to me that printers >deserve their own independent organization due to their pervasive >presence and significant multi-platform problems. And when it comes >to numbers, are MFP devices expected to outnumber printer devices >in the near future? I would be willing to wager with you that in the near future, the number of MFP devices offering at least one additional feature other than printing will exceed single-function printing. If you include facsimile machines, this is one form of multifunction device that probably exceeds printers in sheer numbers. As these obtain an interface cable which could be attached to the computer, I believe MFPs will easily exceed the single function devices. If you have the numbers on fax machines and connected MFPs, I would bet that these outweigh computer printers. Every office has a fax machine, even if they don't have a computer. >The totally sad and sorry state of multi-platform printing atests >to the need for some sort of serious, long-term, industry-wide >organization that is relatively independent. Just my opinion... Good point. Such a sorry state is exactly why organizations form. Until now, we had single-function groups like PWG that didn't want to admit that MFPs were a good idea. We heard about MFPs for years (sort of like color printing was talked about for a long time). Indeed color printing is no longer just a gleam in the marketing groups eye, it is a major printer market area. *** TAKE SPECIAL NOTE: Since MFPs will become more important in the future, it is important for us to get together now, and have harmonious standards for both MFPs that include printer subsystems and single-function printers. *** Let me make a proposal for the PWG. Be involved in the Network device management aspect of printers, as you are now. But recognize that the IETF and DMTF are the main players here. Reorient yourself toward general printing topics. The Job MIB is perhaps a good step in the right direction. Also, some of the topics that Geoff Slater broached, albeit coursely, would also be of interest. Of course, I have an interest in getting attention on my topics as well. The reason I suggest an open mind with working with the MFPA is that we have already done the "dirty work" with regard to setting up a organizational shell, although it is not a sanctioned standards body (nor does it want to be). Printers are an important subsystem within the MFP. MFPA can provide marketing exposure (press releases, etc.) and include more printer topics at our annual Integrated Office Conference (coming up October 21-23). If you need coverage by a sanctioned organization, we have a number of connections in this regard. Just an idea. There is a reality check here though. It is not free if you want to establish such an organization. Figure on some sort of member fee unless you can get rights to publish your own documents. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ > Well, let's not use the term "Media". That sounds like paper or > transparencies, etc. to me. If we use "File Format" or "Format and Protocol" > I will go along with that. I'm using the terminology from RFC 1521, 1522, and 1590 and various other MIME documents. I agree that the word "media" is confusing, but after all, a "multimedia presentation" doesn't mean that you use paper or transparencies. It's an unfortunate word choice, though, for those who want to talk about paper media for printers. ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-imt-04.txt and ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-reg-03.txt are proposed revisions to the MIME specs around "internet media types". For example, the -mime-reg document suggests that media types have parameters, which might be used, for example, to define elements such as a "revision". > You may be asking "Why be so precise -- Why not use the definitions for body > types from MIME". I would be happy to be able to use the MIME types, but > they are insufficient when a PDL is sent to a receiving Dial-up device for > printing without user interaction. You see, MIME assumes a great deal of > user interaction which we do not have the luxury of in the case of MFP's > with no attached user, but still the desire to render and print the document > at the dial-up site. I don't know about "user interaction", but. MIME was designed for a non-interactive application: email delivery. If you have no opportunity to interact with the ultimate recipient, you must just guess as to which kind of formats they can accept (or, as MIME suggests, provide alternatives!) It's only when you have a live interactive connection that you might want to negotiate about precisely what version the recipient device might want optimally. Larry Jay... At 10:37 PM 4/22/96 EDT, JK Martin wrote: >Ray, > >> If you want to remain relatively independent, I can't blame you. MFPA has >> found that we need to be involved in many overlapping standards groups, and >> this was the primary impetus behind remaining somewhat independent, although >> we run our standards strictly through accredited standards bodies, whenever >> possible, such as TIA, IEEE, AIIM, etc. > >Why didn't the MFPA find "shelter" under one of the "umbrella" organizations? >I find this most interesting, indeed. We have from the start. We work closely with TIA and the facsimile standards committee. I am the Vice Chair of TIA TR29.2. Fax is the most standards-sensitive part of an MFP. However, the fax folks don't like to get involved in printer-only or scanner-only stuff. Meanwhile, printer groups and scanner groups could care less about fax stuff, or for that matter, printer groups don't care about scanner stuff. Imagine if you would, a person coming to the printer working group with a proposal to work on the Scanner MIB, of maybe the Fax MIB. Would it fly? I doubt it. As it is, there is a bunch of printer stuff (finishing) that was subtracted from the purview of the PWG and sent to the LMO group. As it is, I have had a hard time getting much support for the PWG to work on printer-oriented work that is just slightly off the train of thought of the PWG. The MFPA is not trying to be a sanctioned standards body. We are a trade association, albeit technically oriented and with an agenda to get the MFP-oriented standards pushed through the various committees. My suggestion below is that I think a real (more general) PWG is quite synergistic with the agenda of the MFPA. However, reality is reality, and the PWG is a nice collection of companies working on printers from one angle or another. And your current focus is useful, but I am afraid that the printer MIB is perhaps already too printer centric to be easily extended to MFP use. A good related question to ask is "When do competitive companies work together?". The answer is simple, "Only when absolutely necessary". My friend, Ken Krechmer of ACTION Consulting has a good quote: "Communication requires standards and standards require communication." He makes the point that standards are only needed when products or things must communicate. These agreements allow everything to work together more easily. In this age of communication, standards have become very important. It turns out that MFP's involve communications and therefore standards are indeed important. >> Certainly MFPA is willing to work with you on any creative ideas. Since the >> printer is a major portion of the MFP device, a printer standards groups >> seems reasonable. However, the PWG is not really a Printer WG, but a >> "Distributed Printer Management WG"; very specific albeit important at the >> moment. The PWG's mission statement is perhaps the first place to start to >> get an understanding of the wishes of the group. > >Hmmm. PWG has too narrow a focus? I wonder what others think about this, >particularly when compared to the MFPA. MFPA is involved in many standards bodies. We have a large focus because an MFP contains many devices, printers, scanners, facsimile, finishing, data modem, voice answering devices, etc. etc. Granted, you have to have some sort of focus or you will be too general. Our focus is at a different "plane", somewhat more market oriented. >For fear of appearing to be "PWG vs. MFPA" (which is NOT what I intend, >I assure you), it just seems strange to me that the MFPA would seek >independent organizational status, but that (in your opinion) the PWG >should not. You misunderstand. MFPA **IS NOT** a standards body and **IS NOT** sanctioned. We take the adoptee role with TIA, AIIM, IEEE, etc. However, we exist as a trade association with bylaws and other organizational documents and when necessary we will create and promote marketing and technical specifications. Printer standards groups already exist. However, there is little impetus to printer people cooperating since there is little "communication". If you succumb to the domination of the major (unnamed, but look at the list for MFPs) printer languages, then most of the printer communication and protocol has been completed, and there is little work to do. Certainly standards-based printer languages were tried, and many companies tried to hang their hat on these. Too bad that TIPSI (NPAP) was so printer centric, or there would be more interest in it by MFPA and the MFP industry. So I am happy to see the printer companies working together on printer management. As you may remember, printer management, and network management in general was a horrible problem until the recent improvements. And there is still work to be done. But the larger scope here is "Network Device Management". PWG does not have this broad scope. To narrow it to network Printer management means that the group will ignore all other sort of devices, this is not a good solution. >Perhaps the sheer numbers of printers currently installed is not >relevant in this topic, but it would seem to me that printers >deserve their own independent organization due to their pervasive >presence and significant multi-platform problems. And when it comes >to numbers, are MFP devices expected to outnumber printer devices >in the near future? I would be willing to wager with you that in the near future, the number of MFP devices offering at least one additional feature other than printing will exceed single-function printing. If you include facsimile machines, this is one form of multifunction device that probably exceeds printers in sheer numbers. As these obtain an interface cable which could be attached to the computer, I believe MFPs will easily exceed the single function devices. If you have the numbers on fax machines and connected MFPs, I would bet that these outweigh computer printers. Every office has a fax machine, even if they don't have a computer. >The totally sad and sorry state of multi-platform printing atests >to the need for some sort of serious, long-term, industry-wide >organization that is relatively independent. Just my opinion... Good point. Such a sorry state is exactly why organizations form. Until now, we had single-function groups like PWG that didn't want to admit that MFPs were a good idea. We heard about MFPs for years (sort of like color printing was talked about for a long time). Indeed color printing is no longer just a gleam in the marketing groups eye, it is a major printer market area. *** TAKE SPECIAL NOTE: Since MFPs will become more important in the future, it is important for us to get together now, and have harmonious standards for both MFPs that include printer subsystems and single-function printers. *** Let me make a proposal for the PWG. Be involved in the Network device management aspect of printers, as you are now. But recognize that the IETF and DMTF are the main players here. Reorient yourself toward general printing topics. The Job MIB is perhaps a good step in the right direction. Also, some of the topics that Geoff Slater broached, albeit coursely, would also be of interest. Of course, I have an interest in getting attention on my topics as well. The reason I suggest an open mind with working with the MFPA is that we have already done the "dirty work" with regard to setting up a organizational shell, although it is not a sanctioned standards body (nor does it want to be). Printers are an important subsystem within the MFP. MFPA can provide marketing exposure (press releases, etc.) and include more printer topics at our annual Integrated Office Conference (coming up October 21-23). If you need coverage by a sanctioned organization, we have a number of connections in this regard. Just an idea. There is a reality check here though. It is not free if you want to establish such an organization. Figure on some sort of member fee unless you can get rights to publish your own documents. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ > Well, let's not use the term "Media". That sounds like paper or > transparencies, etc. to me. If we use "File Format" or "Format and Protocol" > I will go along with that. I'm using the terminology from RFC 1521, 1522, and 1590 and various other MIME documents. I agree that the word "media" is confusing, but after all, a "multimedia presentation" doesn't mean that you use paper or transparencies. It's an unfortunate word choice, though, for those who want to talk about paper media for printers. ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-imt-04.txt and ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-reg-03.txt are proposed revisions to the MIME specs around "internet media types". For example, the -mime-reg document suggests that media types have parameters, which might be used, for example, to define elements such as a "revision". > You may be asking "Why be so precise -- Why not use the definitions for body > types from MIME". I would be happy to be able to use the MIME types, but > they are insufficient when a PDL is sent to a receiving Dial-up device for > printing without user interaction. You see, MIME assumes a great deal of > user interaction which we do not have the luxury of in the case of MFP's > with no attached user, but still the desire to render and print the document > at the dial-up site. I don't know about "user interaction", but. MIME was designed for a non-interactive application: email delivery. If you have no opportunity to interact with the ultimate recipient, you must just guess as to which kind of formats they can accept (or, as MIME suggests, provide alternatives!) It's only when you have a live interactive connection that you might want to negotiate about precisely what version the recipient device might want optimally. Larry > Well, let's not use the term "Media". That sounds like paper or > transparencies, etc. to me. If we use "File Format" or "Format and Protocol" > I will go along with that. I'm using the terminology from RFC 1521, 1522, and 1590 and various other MIME documents. I agree that the word "media" is confusing, but after all, a "multimedia presentation" doesn't mean that you use paper or transparencies. It's an unfortunate word choice, though, for those who want to talk about paper media for printers. ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-imt-04.txt and ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-reg-03.txt are proposed revisions to the MIME specs around "internet media types". For example, the -mime-reg document suggests that media types have parameters, which might be used, for example, to define elements such as a "revision". > You may be asking "Why be so precise -- Why not use the definitions for body > types from MIME". I would be happy to be able to use the MIME types, but > they are insufficient when a PDL is sent to a receiving Dial-up device for > printing without user interaction. You see, MIME assumes a great deal of > user interaction which we do not have the luxury of in the case of MFP's > with no attached user, but still the desire to render and print the document > at the dial-up site. I don't know about "user interaction", but. MIME was designed for a non-interactive application: email delivery. If you have no opportunity to interact with the ultimate recipient, you must just guess as to which kind of formats they can accept (or, as MIME suggests, provide alternatives!) It's only when you have a live interactive connection that you might want to negotiate about precisely what version the recipient device might want optimally. Larry Hi Larry: At 11:25 PM 4/22/96 PDT, Larry Masinter wrote: >> Well, let's not use the term "Media". That sounds like paper or >> transparencies, etc. to me. If we use "File Format" or "Format and Protocol" >> I will go along with that. > >I'm using the terminology from RFC 1521, 1522, and 1590 and various >other MIME documents. I agree that the word "media" is confusing, but >after all, a "multimedia presentation" doesn't mean that you use paper >or transparencies. It's an unfortunate word choice, though, for those >who want to talk about paper media for printers. I think the MIME documents are out of line here. MultiMedia refers to the final communication media, i.e. sound waves (sound) Visual (CRT) etc. Even if you decide that you want to use paper as the media, there are still a kazillion file formats to express the content on the media. >ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-imt-04.txt >and >ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-reg-03.txt >are proposed revisions to the MIME specs around "internet media >types". For example, the -mime-reg document suggests that media types >have parameters, which might be used, for example, to define elements >such as a "revision". I'll look these up. >> You may be asking "Why be so precise -- Why not use the definitions for body >> types from MIME". I would be happy to be able to use the MIME types, but >> they are insufficient when a PDL is sent to a receiving Dial-up device for >> printing without user interaction. You see, MIME assumes a great deal of >> user interaction which we do not have the luxury of in the case of MFP's >> with no attached user, but still the desire to render and print the document >> at the dial-up site. > >I don't know about "user interaction", but. MIME was designed for a >non-interactive application: email delivery. If you have no >opportunity to interact with the ultimate recipient, you must just >guess as to which kind of formats they can accept (or, as MIME >suggests, provide alternatives!) Since User Interaction is still confusing, let me try to clarify. With Email, it is assumed that you are communicating directly with a user, i.e. although the transport of the file is non-interactive (for the most part), the intention is that the end will look at the file and decide which application it can be used with. You can tell if User Interaction is required if you ever see someone using the mouse or keyboard when sending or receiving mail. Frequently, the email will have an attachment. If you don't have an application that is set up for it, then you have to send email back to say that it is the wrong format. The USER on the other side then works with the USER on the destination to select a format which is acceptable. For me, this frequently happens with a telephone call. Now examine Facsimile. As old as it may be, it handles all the negotiation for final delivery or the sender is immediately notified that it didn't work. There is no need for a telephone call in advance and no need for mice or keyboards on fax machines (stand-alone variety). Is fax the best protocol of all? Well, no, and there are proposals for improvement. I Hope this clarifies the concept of interactive. >It's only when you have a live interactive connection that you might >want to negotiate about precisely what version the recipient device >might want optimally. Not True! I have to do it by telephone now or manually by email. email and other forms of communication and the memory available ALLOWS optimized transmissions. Your conclusion is based on one assumption: we know nothing about the recipient device in advance. It is perfectly reasonable to discover the capabilities of a recipient with a preliminary communication. This does not have to occur on a live interactive connection. In fact, if you are sending say Postscript and you know that it will take a long time to render if the recipient only takes Group 3 fax formats, then the live interactive telephone calls are typically terminated and the rendering is done off-line. Larry: It appears that the MIME working groups are in an area that the MFPA will want more involvement. (I will review the docs to make sure). What are names of the mailing lists or meeting times, etc? -Raymond Dear MFPA: I have been working on the Troika API over the last several weeks. This is based on code that we developed, although the interface described by this document is "improved" somewhat, based on our experience with that project. This is a draft document. I think the CX... section and PKT... sections are fairly firm, while the MF... section is still being developed. At this point, please review this from an architectural standpoint with detailed comments on the CX... and PKT... sections. I will be providing updates between now and our upcoming meeting as well. This document is drafted as if it were an ANNEX to the IS-650 document, so many of the terms and the like are adopted from IS-650. I'm still not sure what the actual form of the document will take, but I am tending toward making it a separate document rather than an annex. The document may be found as: ftp://ftp.cts.com/pub/MFPA/troika04.doz It is a WinWord 6.0 file that has been PKZIPPED using the encryption option. The password is the same as used with the IS-650 document. Please call MFPA headquarters if you need the password. -Raymond At 06:50 AM 4/23/96 MDT, deBry, Roger K. wrote: >This reminds me of the old saying, "standards must be a good thing, there >are so many of them." Roger, your humorous saying is a nice touch, but I am wondering what your point is. Here is the law of nature: Standards are REQUIRED for communication of any kind. For humans, we must agree on the meaning of the symbols that you are reading, and the semantics of their combinations. Sorry, any debate about whether standards are required is just simply a waste of time. Certainly, there are many standards that are just paper documents which claim to be "standards" but in fact are only documents. A standard is something that is widely, if not globally used. Is it ok to have multiple standards? You bet. But there is a cost in lower interoperability. I think people confuse standards documentation with real standards, that are globally implemented. If you look at it this way, there really aren't that many standards. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Larry: At 11:25 PM 4/22/96 PDT, Larry Masinter wrote: >> Well, let's not use the term "Media". That sounds like paper or >> transparencies, etc. to me. If we use "File Format" or "Format and Protocol" >> I will go along with that. > >I'm using the terminology from RFC 1521, 1522, and 1590 and various >other MIME documents. I agree that the word "media" is confusing, but >after all, a "multimedia presentation" doesn't mean that you use paper >or transparencies. It's an unfortunate word choice, though, for those >who want to talk about paper media for printers. I think the MIME documents are out of line here. MultiMedia refers to the final communication media, i.e. sound waves (sound) Visual (CRT) etc. Even if you decide that you want to use paper as the media, there are still a kazillion file formats to express the content on the media. >ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-imt-04.txt >and >ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-reg-03.txt >are proposed revisions to the MIME specs around "internet media >types". For example, the -mime-reg document suggests that media types >have parameters, which might be used, for example, to define elements >such as a "revision". I'll look these up. >> You may be asking "Why be so precise -- Why not use the definitions for body >> types from MIME". I would be happy to be able to use the MIME types, but >> they are insufficient when a PDL is sent to a receiving Dial-up device for >> printing without user interaction. You see, MIME assumes a great deal of >> user interaction which we do not have the luxury of in the case of MFP's >> with no attached user, but still the desire to render and print the document >> at the dial-up site. > >I don't know about "user interaction", but. MIME was designed for a >non-interactive application: email delivery. If you have no >opportunity to interact with the ultimate recipient, you must just >guess as to which kind of formats they can accept (or, as MIME >suggests, provide alternatives!) Since User Interaction is still confusing, let me try to clarify. With Email, it is assumed that you are communicating directly with a user, i.e. although the transport of the file is non-interactive (for the most part), the intention is that the end will look at the file and decide which application it can be used with. You can tell if User Interaction is required if you ever see someone using the mouse or keyboard when sending or receiving mail. Frequently, the email will have an attachment. If you don't have an application that is set up for it, then you have to send email back to say that it is the wrong format. The USER on the other side then works with the USER on the destination to select a format which is acceptable. For me, this frequently happens with a telephone call. Now examine Facsimile. As old as it may be, it handles all the negotiation for final delivery or the sender is immediately notified that it didn't work. There is no need for a telephone call in advance and no need for mice or keyboards on fax machines (stand-alone variety). Is fax the best protocol of all? Well, no, and there are proposals for improvement. I Hope this clarifies the concept of interactive. >It's only when you have a live interactive connection that you might >want to negotiate about precisely what version the recipient device >might want optimally. Not True! I have to do it by telephone now or manually by email. email and other forms of communication and the memory available ALLOWS optimized transmissions. Your conclusion is based on one assumption: we know nothing about the recipient device in advance. It is perfectly reasonable to discover the capabilities of a recipient with a preliminary communication. This does not have to occur on a live interactive connection. In fact, if you are sending say Postscript and you know that it will take a long time to render if the recipient only takes Group 3 fax formats, then the live interactive telephone calls are typically terminated and the rendering is done off-line. Larry: It appears that the MIME working groups are in an area that the MFPA will want more involvement. (I will review the docs to make sure). What are names of the mailing lists or meeting times, etc? -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ At 06:50 AM 4/23/96 MDT, deBry, Roger K. wrote: >This reminds me of the old saying, "standards must be a good thing, there >are so many of them." Roger, your humorous saying is a nice touch, but I am wondering what your point is. Here is the law of nature: Standards are REQUIRED for communication of any kind. For humans, we must agree on the meaning of the symbols that you are reading, and the semantics of their combinations. Sorry, any debate about whether standards are required is just simply a waste of time. Certainly, there are many standards that are just paper documents which claim to be "standards" but in fact are only documents. A standard is something that is widely, if not globally used. Is it ok to have multiple standards? You bet. But there is a cost in lower interoperability. I think people confuse standards documentation with real standards, that are globally implemented. If you look at it this way, there really aren't that many standards. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Larry: At 11:25 PM 4/22/96 PDT, Larry Masinter wrote: >> Well, let's not use the term "Media". That sounds like paper or >> transparencies, etc. to me. If we use "File Format" or "Format and Protocol" >> I will go along with that. > >I'm using the terminology from RFC 1521, 1522, and 1590 and various >other MIME documents. I agree that the word "media" is confusing, but >after all, a "multimedia presentation" doesn't mean that you use paper >or transparencies. It's an unfortunate word choice, though, for those >who want to talk about paper media for printers. I think the MIME documents are out of line here. MultiMedia refers to the final communication media, i.e. sound waves (sound) Visual (CRT) etc. Even if you decide that you want to use paper as the media, there are still a kazillion file formats to express the content on the media. >ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-imt-04.txt >and >ftp://ds.internic.net/internet/drafts/draft-ietf-822ext-mime-reg-03.txt >are proposed revisions to the MIME specs around "internet media >types". For example, the -mime-reg document suggests that media types >have parameters, which might be used, for example, to define elements >such as a "revision". I'll look these up. >> You may be asking "Why be so precise -- Why not use the definitions for body >> types from MIME". I would be happy to be able to use the MIME types, but >> they are insufficient when a PDL is sent to a receiving Dial-up device for >> printing without user interaction. You see, MIME assumes a great deal of >> user interaction which we do not have the luxury of in the case of MFP's >> with no attached user, but still the desire to render and print the document >> at the dial-up site. > >I don't know about "user interaction", but. MIME was designed for a >non-interactive application: email delivery. If you have no >opportunity to interact with the ultimate recipient, you must just >guess as to which kind of formats they can accept (or, as MIME >suggests, provide alternatives!) Since User Interaction is still confusing, let me try to clarify. With Email, it is assumed that you are communicating directly with a user, i.e. although the transport of the file is non-interactive (for the most part), the intention is that the end will look at the file and decide which application it can be used with. You can tell if User Interaction is required if you ever see someone using the mouse or keyboard when sending or receiving mail. Frequently, the email will have an attachment. If you don't have an application that is set up for it, then you have to send email back to say that it is the wrong format. The USER on the other side then works with the USER on the destination to select a format which is acceptable. For me, this frequently happens with a telephone call. Now examine Facsimile. As old as it may be, it handles all the negotiation for final delivery or the sender is immediately notified that it didn't work. There is no need for a telephone call in advance and no need for mice or keyboards on fax machines (stand-alone variety). Is fax the best protocol of all? Well, no, and there are proposals for improvement. I Hope this clarifies the concept of interactive. >It's only when you have a live interactive connection that you might >want to negotiate about precisely what version the recipient device >might want optimally. Not True! I have to do it by telephone now or manually by email. email and other forms of communication and the memory available ALLOWS optimized transmissions. Your conclusion is based on one assumption: we know nothing about the recipient device in advance. It is perfectly reasonable to discover the capabilities of a recipient with a preliminary communication. This does not have to occur on a live interactive connection. In fact, if you are sending say Postscript and you know that it will take a long time to render if the recipient only takes Group 3 fax formats, then the live interactive telephone calls are typically terminated and the rendering is done off-line. Larry: It appears that the MIME working groups are in an area that the MFPA will want more involvement. (I will review the docs to make sure). What are names of the mailing lists or meeting times, etc? -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Dear MFPA: I have been working on the Troika API over the last several weeks. This is based on code that we developed, although the interface described by this document is "improved" somewhat, based on our experience with that project. This is a draft document. I think the CX... section and PKT... sections are fairly firm, while the MF... section is still being developed. At this point, please review this from an architectural standpoint with detailed comments on the CX... and PKT... sections. I will be providing updates between now and our upcoming meeting as well. This document is drafted as if it were an ANNEX to the IS-650 document, so many of the terms and the like are adopted from IS-650. I'm still not sure what the actual form of the document will take, but I am tending toward making it a separate document rather than an annex. The document may be found as: ftp://ftp.cts.com/pub/MFPA/troika04.doz It is a WinWord 6.0 file that has been PKZIPPED using the encryption option. The password is the same as used with the IS-650 document. Please call MFPA headquarters if you need the password. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ FOR IMMEDIATE RELEASE: Multifunction Peripheral Association (MFPA) to Host "Integrated Office Conference '96" Second annual conference on multifunction products and technologies set for October 21 - 23, 1996 in San Diego, California SAN DIEGO, CA / April 18, 1996 - The Multifunction Peripheral Association (MFPA), an industry group composed of leading printer, copier, fax, modem and scanner manufacturers, today announced it will hold its second annual "Integrated Office Conference" (IOC '96) from October 21 - 23 at the Mission Valley Marriott in San Diego, California. Held in cooperation with the Telecommunications Industry Association (TIA), IOC '96 offers critical technical and strategic information about the design and development of multifunction peripherals (MFPs or products that combine fax, data transfer, scanning, copying and/or printing features in one unit). IOC '96 also provides a forum for product development professionals to directly influence proposed industry standards for MFPs and their component technologies. The conference features a full range of seminars, presentations, panel discussions and speeches as well as hosted meals and special events. Three tracks of eighteen sessions covering technical and marketing issues are scheduled along with an exhibit hall for manufacturers and developers to display their products and services. An optional pre-conference Communications Standards Briefing will be conducted by TIA. Also scheduled are presentations and discussions of the MFPA's own Multifunction Peripheral Interface (MFPI) standard; which has been accepted by the TIA as its interim standard IS-650. Designed to facilitate communications between MFPs as well as for compatibility with popular network and operating system architectures, the MFPI standard promises to make multifunction products easier to develop, less expensive and more compatible across a wide range of platforms. According to MFPA Executive Council Chair, Raymond Lutz, "IOC '96 is the computer industry's most important forum for the exchange of ideas and information on multifunction products. IOC '95 drew over 150 top industry development professionals and executives from around the world. Based on our preliminary surveys, were expecting over 200 attendees for IOC '96." "Our corporate members, which include some of the biggest names in the industry, are actively developing MFPs and working to support the MFPA's own emerging standards. So, even those involved with development of related products such as printers, scanners, fax machines, modems or copiers need to know where the industry as a whole is headed. IOC '96 is the perfect opportunity to see all the core technologies at once," continued Lutz. Ron Albeck, IOC '96 Chairman, added, "The projected numbers for MFP sales are huge but the road to profits will be treacherous if a developer chooses the wrong direction. IOC '96 is a "must attend" event for managers who want to understand all the issues before making their companys critical design decisions." The registration fee for IOC '96 is $795 for MFPA members and $895 for nonmembers. Admission includes access to all regular conference sessions, continental breakfasts, a hosted luncheon, networking receptions, and a complete conference binder. (The TIA standards briefing is optional and pricing is TBD.) Audio transcriptions will also be available for most conference sessions. A $100 discount will apply to registrations received prior to September 13. Discounted hotel rates are available for reservations made by September 21. For further information, contact the MFPA toll-free at 800-603-MFPA, via fax at 619-447-6872 or by mail at: MFPA, 1010 Old Chase Avenue, Suite B, El Cajon, CA 92020. Information is also available via Internet by sending an e-mail message to "mfpa-request@mfpa.org" with the subject "Send IOC 96 Info" or from the MFPA's worldwide web site at http://www.mfpa.org. --------------- The Multifunction Peripheral Association (MFPA) is an industry association established for the promotion and development of multifunction computer peripheral devices and uniform standards for computer-based faxing, data transfer, scanning, printing and copying. Member companies and sponsors of the MFPI / IS-650 standard include: Advanced Hardware Architects, AMP Incorporated, Brother International, Canon USA, Cognisys, Danka/Omnifax, Destiny Technology, Device Guys, EPSON, Fujitsu, IBM, Imsys AB, Konica Business Machines, Lanier Worldwide, Matsushita Electric, Minolta, Mita Copystar, Motorola, National Semiconductor, Oce, Okidata, Peerless Systems, Pixel Magic, QMS, Questra, Ricoh, Rockwell Telecommunications, Sharp, Torrey Pines Research, Toshiba America, WindRiver Systems, Wordcraft Systems, Xerox and Xionics Document Technologies. Raymond Lutz, MFPA Executive Council Chair, is Director of R & D for Cognisys, Inc., a national contract engineering firm and multifunction product developer. Ron Albeck, IOC '96 Chairman, is Digital Product Planning Manager for Mita, a worldwide provider of copiers, laser, fax and multifunctional document imaging systems. ### FOR IMMEDIATE RELEASE: MEDIA CONTACT: Tom Geldner Geldner Associates Tel: (619) 578-0096 Fax: (619) 578-0828 Internet: 72650.1142@compuserve.com Multifunction Peripheral Association (MFPA) to Host "Integrated Office Conference '96" Second annual conference on multifunction products and technologies set for October 21 - 23, 1996 in San Diego, California SAN DIEGO, CA / April 18, 1996 - The Multifunction Peripheral Association (MFPA), an industry group composed of leading printer, copier, fax, modem and scanner manufacturers, today announced it will hold its second annual "Integrated Office Conference" (IOC '96) from October 21 - 23 at the Mission Valley Marriott in San Diego, California. Held in cooperation with the Telecommunications Industry Association (TIA), IOC '96 offers critical technical and strategic information about the design and development of multifunction peripherals (MFPs or products that combine fax, data transfer, scanning, copying and/or printing features in one unit). IOC '96 also provides a forum for product development professionals to directly influence proposed industry standards for MFPs and their component technologies. The conference features a full range of seminars, presentations, panel discussions and speeches as well as hosted meals and special events. Three tracks of eighteen sessions covering technical and marketing issues are scheduled along with an exhibit hall for manufacturers and developers to display their products and services. An optional pre-conference Communications Standards Briefing will be conducted by TIA. Also scheduled are presentations and discussions of the MFPA's own Multifunction Peripheral Interface (MFPI) standard; which has been accepted by the TIA as its interim standard IS-650. Designed to facilitate communications between MFPs as well as for compatibility with popular network and operating system architectures, the MFPI standard promises to make multifunction products easier to develop, less expensive and more compatible across a wide range of platforms. According to MFPA Executive Council Chair, Raymond Lutz, "IOC '96 is the computer industry's most important forum for the exchange of ideas and information on multifunction products. IOC '95 drew over 150 top industry development professionals and executives from around the world. Based on our preliminary surveys, were expecting over 200 attendees for IOC '96." "Our corporate members, which include some of the biggest names in the industry, are actively developing MFPs and working to support the MFPA's own emerging standards. So, even those involved with development of related products such as printers, scanners, fax machines, modems or copiers need to know where the industry as a whole is headed. IOC '96 is the perfect opportunity to see all the core technologies at once," continued Lutz. Ron Albeck, IOC '96 Chairman, added, "The projected numbers for MFP sales are huge but the road to profits will be treacherous if a developer chooses the wrong direction. IOC '96 is a "must attend" event for managers who want to understand all the issues before making their companys critical design decisions." The registration fee for IOC '96 is $795 for MFPA members and $895 for nonmembers. Admission includes access to all regular conference sessions, continental breakfasts, a hosted luncheon, networking receptions, and a complete conference binder. (The TIA standards briefing is optional and pricing is TBD.) Audio transcriptions will also be available for most conference sessions. A $100 discount will apply to registrations received prior to September 13. Discounted hotel rates are available for reservations made by September 21. For further information, contact the MFPA toll-free at 800-603-MFPA, via fax at 619-447-6872 or by mail at: MFPA, 1010 Old Chase Avenue, Suite B, El Cajon, CA 92020. Information is also available via Internet by sending an e-mail message to "mfpa-request@mfpa.org" with the subject "Send IOC 96 Info" or from the MFPA's worldwide web site at http://www.mfpa.org. --------------- The Multifunction Peripheral Association (MFPA) is an industry association established for the promotion and development of multifunction computer peripheral devices and uniform standards for computer-based faxing, data transfer, scanning, printing and copying. Member companies and sponsors of the MFPI / IS-650 standard include: Advanced Hardware Architects, AMP Incorporated, Brother International, Canon USA, Cognisys, Danka/Omnifax, Destiny Technology, Device Guys, EPSON, Fujitsu, IBM, Imsys AB, Konica Business Machines, Lanier Worldwide, Matsushita Electric, Minolta, Mita Copystar, Motorola, National Semiconductor, Oce, Okidata, Peerless Systems, Pixel Magic, QMS, Questra, Ricoh, Rockwell Telecommunications, Sharp, Torrey Pines Research, Toshiba America, WindRiver Systems, Wordcraft Systems, Xerox and Xionics Document Technologies. Raymond Lutz, MFPA Executive Council Chair, is Director of R & D for Cognisys, Inc., a national contract engineering firm and multifunction product developer. Ron Albeck, IOC '96 Chairman, is Digital Product Planning Manager for Mita, a worldwide provider of copiers, laser, fax and multifunctional document imaging systems. ### MEDIA CONTACT: Tom Geldner Geldner Associates Tel: (619) 578-0096 Fax: (619) 578-0828 Internet: 72650.1142@compuserve.com !^NavFont02F23220006MGHHjk16DE ------------------------------------------------------ Tom Geldner Tel: 619/578-0096 Agency Principal Fax: 619/578-0828 Geldner Associates 72650.1142@compuserve.com 7830 Norcanyon Way San Diego, CA 92126 Full-service marketing, advertising & public relations Visit our WWW site at: http://ourworld.compuserve.com/homepages/geldner ------------------------------------------------------ After an internal meeting yesterday, there are a few significant changes to the Troika API document. I will be editing this document tonite and I hope to get most of the know changes incorporated. So, in the meantime, please read it with a "grain of salt". I was just now speaking with Ted Lappin (Exabyte) who is the techical editor of the SCSI-3 document that we were using for IS-650. He suggests some changes: - Use BUSY instead of CONDITION_MET status when the Target wishes to accept the header but decline the content. - Use the Device Type indicator for Communication Devices. The idea of asking for a special device type for multifunction devices is something that we can discuss with the X3T10 group, but this will be the best legal setting for now. - Consider using DISCONNECT as a means to start a GET MESSAGE command and allow the target to wait until it has a packet to send back. This could be used instead of polling the target. ***NOTICE*** Please produce comments on IS-650 this week if possible. -Raymond After an internal meeting yesterday, there are a few significant changes to the Troika API document. I will be editing this document tonite and I hope to get most of the know changes incorporated. So, in the meantime, please read it with a "grain of salt". I was just now speaking with Ted Lappin (Exabyte) who is the techical editor of the SCSI-3 document that we were using for IS-650. He suggests some changes: - Use BUSY instead of CONDITION_MET status when the Target wishes to accept the header but decline the content. - Use the Device Type indicator for Communication Devices. The idea of asking for a special device type for multifunction devices is something that we can discuss with the X3T10 group, but this will be the best legal setting for now. - Consider using DISCONNECT as a means to start a GET MESSAGE command and allow the target to wait until it has a packet to send back. This could be used instead of polling the target. ***NOTICE*** Please produce comments on IS-650 this week if possible. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Raymond, This is sure to draw a lot of comment, as the channels group was created as a catchall and has cause very much confusion. It is alternately attached as not having enough information or being unnecessary. The last PWG meeting did consider various proposals to improve the group, and the current idea is to link it to another MIB that will provide more information... note will be out shortly. But, most of your questions are answered by the text in the rfc1759. Channel (which is perhaps an unfortunate name) is not the same as connection. Connection information is provided by reference to the interface table in MIB-2 (probably as modified by the extensions to the interface group , rfc1573). Although there is some potential for confusion here, insofar as there may be several protocol layers that may be involved, the intent was that the interface table entry to which the channel entry pointed did indicate the physical connection. The other mib reference being considered might be usable to identify intermediate layers) The mib-2 reference therefore deals with USB, Firewire, Ethernet 10BaseT 10Base2, as well as EIA232, IEEE1284, etc. So why do some low level interfaces appear under channels? Well, channels deals with the data source just before the interpreter. If there is no print service or spooler application, (raw data stream transported from host to interpreter), then that interface or whatever is the channel. If you had TIPSI over IEEE1284, the channel would be TIPSI. If you had LPD over PPP over serial, the channel would be LPD. But if you had a simple data stream transport over serial, the channel is serial. Lexmark could answer this better, but NPAP is listed as an interpreter language in that it is a control language. Part of the control function is job direction to an appropriate print language interpreter. Therefore, it does represent a channel. TIPSI is distinct from NPAP and had been added to the list. However, since rfc's do not get updated, the list must be obtained from the PWG or IANA. There are PAP's other than AppleTalk. If one wanted to use AppleTalk in a 'raw' mode (as is being done) it would require another channel entry. There is an effort to provide more information. But there is nothing to say that the details of a channel must be public. One could very well want a private proprietary channel, in which case the identification has the function of indicating that it is not a well known channel. Since one of the main purposes of the channel is to provide a tag to control an on/off switch (passing data to an interpreter), much of the function is just in having a unique name. We have been waiting for someone who knows about fax to make some suggestions/clarifications there, or perhaps to define some new channels. Your suggestion should be considered. But it would seem to complicate matters to change a simple enum into a multi-tiered structure. To 'whittle away the list to some popular subset' (as has been suggested in limiting printer languages tags to several versions of PCL and PostScript) leaves the obvious question of what do you do if you don't happen to use what some group decided was popular? In addition, it is unclear that there would be any advantage in such a restriction. You don't save any bits and, since a particular application need just deal with what they consider the 'popular subset', you don't save any code. You just make it harder for companies who, for one reason or another, don't fall into the popular subset group. At any rate, the PWG is sensitive to the problems, particularly with channel, and comments such as Raymond's are appreciated in that they point out where more explanation is needed or where change may be desirable. Bill Wagner DPI ______________________________ Reply Separator _________________________________ Subject: Channels Group -- Propose Split Author: raylutz@cognisys.com (Raymond Lutz) at Internet Date: 4/24/96 4:04 PM I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Raymond, This is sure to draw a lot of comment, as the channels group was created as a catchall and has cause very much confusion. It is alternately attached as not having enough information or being unnecessary. The last PWG meeting did consider various proposals to improve the group, and the current idea is to link it to another MIB that will provide more information... note will be out shortly. But, most of your questions are answered by the text in the rfc1759. Channel (which is perhaps an unfortunate name) is not the same as connection. Connection information is provided by reference to the interface table in MIB-2 (probably as modified by the extensions to the interface group , rfc1573). Although there is some potential for confusion here, insofar as there may be several protocol layers that may be involved, the intent was that the interface table entry to which the channel entry pointed did indicate the physical connection. The other mib reference being considered might be usable to identify intermediate layers) The mib-2 reference therefore deals with USB, Firewire, Ethernet 10BaseT 10Base2, as well as EIA232, IEEE1284, etc. So why do some low level interfaces appear under channels? Well, channels deals with the data source just before the interpreter. If there is no print service or spooler application, (raw data stream transported from host to interpreter), then that interface or whatever is the channel. If you had TIPSI over IEEE1284, the channel would be TIPSI. If you had LPD over PPP over serial, the channel would be LPD. But if you had a simple data stream transport over serial, the channel is serial. Lexmark could answer this better, but NPAP is listed as an interpreter language in that it is a control language. Part of the control function is job direction to an appropriate print language interpreter. Therefore, it does represent a channel. TIPSI is distinct from NPAP and had been added to the list. However, since rfc's do not get updated, the list must be obtained from the PWG or IANA. There are PAP's other than AppleTalk. If one wanted to use AppleTalk in a 'raw' mode (as is being done) it would require another channel entry. There is an effort to provide more information. But there is nothing to say that the details of a channel must be public. One could very well want a private proprietary channel, in which case the identification has the function of indicating that it is not a well known channel. Since one of the main purposes of the channel is to provide a tag to control an on/off switch (passing data to an interpreter), much of the function is just in having a unique name. We have been waiting for someone who knows about fax to make some suggestions/clarifications there, or perhaps to define some new channels. Your suggestion should be considered. But it would seem to complicate matters to change a simple enum into a multi-tiered structure. To 'whittle away the list to some popular subset' (as has been suggested in limiting printer languages tags to several versions of PCL and PostScript) leaves the obvious question of what do you do if you don't happen to use what some group decided was popular? In addition, it is unclear that there would be any advantage in such a restriction. You don't save any bits and, since a particular application need just deal with what they consider the 'popular subset', you don't save any code. You just make it harder for companies who, for one reason or another, don't fall into the popular subset group. At any rate, the PWG is sensitive to the problems, particularly with channel, and comments such as Raymond's are appreciated in that they point out where more explanation is needed or where change may be desirable. Bill Wagner DPI ______________________________ Reply Separator _________________________________ Subject: Channels Group -- Propose Split Author: raylutz@cognisys.com (Raymond Lutz) at Internet Date: 4/24/96 4:04 PM I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Raymond, This is sure to draw a lot of comment, as the channels group was created as a catchall and has cause very much confusion. It is alternately attached as not having enough information or being unnecessary. The last PWG meeting did consider various proposals to improve the group, and the current idea is to link it to another MIB that will provide more information... note will be out shortly. But, most of your questions are answered by the text in the rfc1759. Channel (which is perhaps an unfortunate name) is not the same as connection. Connection information is provided by reference to the interface table in MIB-2 (probably as modified by the extensions to the interface group , rfc1573). Although there is some potential for confusion here, insofar as there may be several protocol layers that may be involved, the intent was that the interface table entry to which the channel entry pointed did indicate the physical connection. The other mib reference being considered might be usable to identify intermediate layers) The mib-2 reference therefore deals with USB, Firewire, Ethernet 10BaseT 10Base2, as well as EIA232, IEEE1284, etc. So why do some low level interfaces appear under channels? Well, channels deals with the data source just before the interpreter. If there is no print service or spooler application, (raw data stream transported from host to interpreter), then that interface or whatever is the channel. If you had TIPSI over IEEE1284, the channel would be TIPSI. If you had LPD over PPP over serial, the channel would be LPD. But if you had a simple data stream transport over serial, the channel is serial. Lexmark could answer this better, but NPAP is listed as an interpreter language in that it is a control language. Part of the control function is job direction to an appropriate print language interpreter. Therefore, it does represent a channel. TIPSI is distinct from NPAP and had been added to the list. However, since rfc's do not get updated, the list must be obtained from the PWG or IANA. There are PAP's other than AppleTalk. If one wanted to use AppleTalk in a 'raw' mode (as is being done) it would require another channel entry. There is an effort to provide more information. But there is nothing to say that the details of a channel must be public. One could very well want a private proprietary channel, in which case the identification has the function of indicating that it is not a well known channel. Since one of the main purposes of the channel is to provide a tag to control an on/off switch (passing data to an interpreter), much of the function is just in having a unique name. We have been waiting for someone who knows about fax to make some suggestions/clarifications there, or perhaps to define some new channels. Your suggestion should be considered. But it would seem to complicate matters to change a simple enum into a multi-tiered structure. To 'whittle away the list to some popular subset' (as has been suggested in limiting printer languages tags to several versions of PCL and PostScript) leaves the obvious question of what do you do if you don't happen to use what some group decided was popular? In addition, it is unclear that there would be any advantage in such a restriction. You don't save any bits and, since a particular application need just deal with what they consider the 'popular subset', you don't save any code. You just make it harder for companies who, for one reason or another, don't fall into the popular subset group. At any rate, the PWG is sensitive to the problems, particularly with channel, and comments such as Raymond's are appreciated in that they point out where more explanation is needed or where change may be desirable. Bill Wagner DPI ______________________________ Reply Separator _________________________________ Subject: Channels Group -- Propose Split Author: raylutz@cognisys.com (Raymond Lutz) at Internet Date: 4/24/96 4:04 PM I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Thanks for your thorough explanation. > To 'whittle away the list to some popular subset' (as has been suggested > in limiting printer languages tags to several versions of PCL and > PostScript) leaves the obvious question of what do you do if you don't > happen to use what some group decided was popular? This is easily handled by asked those interested to come up with documentation for the Channel. If someone spends the time and effort to do that, then there is some interest. The problem of trying to include everything in a list that might be important is perhaps a good reason to use OIDs or the "recipe" approach where the standards group only needs to determine HOW to make up the references, not WHAT exactly was made up. > In addition, it is > unclear that there would be any advantage in such a restriction. You > don't save any bits and, since a particular application need just deal > with what they consider the 'popular subset', you don't save any code. > You just make it harder for companies who, for one reason or another, > don't fall into the popular subset group. The advantage of "whittling" is that you remove ambiguities from what you are to be told about the system. If I can't figure out EXACTLY what is meant by some of the entries, what good are they? You may as well just say OTHER, or UNKNOWN. Or, don't try to enumerate and just provide a text string to describe this. Putting a bunch of unknowns into an enumeration makes it less than worthless. Anyway, I will look at the MIB-2 stuff in this regard to see if it has what I need. Thanks again. -Raymond I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ I was looking over the Channels Group of RFC-1759 and I was having a hard time understanding how all this stuff got into one group. Perhaps we can split the group into two groups, one being the CONNECTION group, and another being the CHANNELS or maybe PROTOCOL group. The reason this crops up is some of the entries can be used with others. We could use chDCERemoteProcedureCall(22) on chSerialPort(3), right? We could use chAppSocket(12) on chSerialPort(3), right? We could use chIEEE-1284.4(new) on chIEEE1284(5), right? Where is USB? Where is TCP/IP? Does XXXBaseT belong here? How did stuff like NPAP get here when it is also identified as an interpreter? Should NPAP be renamed TIPSI? chAppleTalkPAP(7) not only names a channel, but also a protocol in one breath. What if you want to use AppleTalk but not PAP? As with PrtInterpreterLangFamily, I would suggest that each one of these have a referenced document, or else throw it out. Stuff like chFax(18) (gag!) is very hard to understand what this is. Anything without so much as a comment should definitely go. Do most people not care about most of these except for a half dozen of them (akin to the PrtInterpreterLangFamily?) Is there a way to whittle these lists down to the popular minimum, and then add a string or someway to allow manufacturer extensions later? (This is the sort of area where a as used in IS-650 comes in handy). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Thanks for your thorough explanation. > To 'whittle away the list to some popular subset' (as has been suggested > in limiting printer languages tags to several versions of PCL and > PostScript) leaves the obvious question of what do you do if you don't > happen to use what some group decided was popular? This is easily handled by asked those interested to come up with documentation for the Channel. If someone spends the time and effort to do that, then there is some interest. The problem of trying to include everything in a list that might be important is perhaps a good reason to use OIDs or the "recipe" approach where the standards group only needs to determine HOW to make up the references, not WHAT exactly was made up. > In addition, it is > unclear that there would be any advantage in such a restriction. You > don't save any bits and, since a particular application need just deal > with what they consider the 'popular subset', you don't save any code. > You just make it harder for companies who, for one reason or another, > don't fall into the popular subset group. The advantage of "whittling" is that you remove ambiguities from what you are to be told about the system. If I can't figure out EXACTLY what is meant by some of the entries, what good are they? You may as well just say OTHER, or UNKNOWN. Or, don't try to enumerate and just provide a text string to describe this. Putting a bunch of unknowns into an enumeration makes it less than worthless. Anyway, I will look at the MIB-2 stuff in this regard to see if it has what I need. Thanks again. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Thanks for your thorough explanation. > To 'whittle away the list to some popular subset' (as has been suggested > in limiting printer languages tags to several versions of PCL and > PostScript) leaves the obvious question of what do you do if you don't > happen to use what some group decided was popular? This is easily handled by asked those interested to come up with documentation for the Channel. If someone spends the time and effort to do that, then there is some interest. The problem of trying to include everything in a list that might be important is perhaps a good reason to use OIDs or the "recipe" approach where the standards group only needs to determine HOW to make up the references, not WHAT exactly was made up. > In addition, it is > unclear that there would be any advantage in such a restriction. You > don't save any bits and, since a particular application need just deal > with what they consider the 'popular subset', you don't save any code. > You just make it harder for companies who, for one reason or another, > don't fall into the popular subset group. The advantage of "whittling" is that you remove ambiguities from what you are to be told about the system. If I can't figure out EXACTLY what is meant by some of the entries, what good are they? You may as well just say OTHER, or UNKNOWN. Or, don't try to enumerate and just provide a text string to describe this. Putting a bunch of unknowns into an enumeration makes it less than worthless. Anyway, I will look at the MIB-2 stuff in this regard to see if it has what I need. Thanks again. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPA MEETING NOTICE -- TOKYO, JAPAN -- MAY 23, 1996 ***PRELIMINARY*** A one-day overview meeting is planned for Tokyo, Japan, on May 23, 1996. The site and arrangements are still not pinned down. However, since I was finding myself in Tokyo on other business, this will work well for everyone. If you are located in Japan or have associates that would like to attend this meeting, please let us know ASAP so that we can make the required arrangements. PLEASE SEND EMAIL TO mfpa-request@mfpa.org IF YOU WISH TO SEND REPRESENTATIVE(S) TO THIS MEETING. The meeting will be primarily a presentation format, with presentation of IS-650 and Troika API, and an overview of the MFPA organization. I will be also investigating a possible Birds of a Feather meeting with Salutation Consortium. -Raymond MFPA MEETING NOTICE -- TOKYO, JAPAN -- MAY 23, 1996 ***PRELIMINARY*** A one-day overview meeting is planned for Tokyo, Japan, on May 23, 1996. The site and arrangements are still not pinned down. However, since I was finding myself in Tokyo on other business, this will work well for everyone. If you are located in Japan or have associates that would like to attend this meeting, please let us know ASAP so that we can make the required arrangements. PLEASE SEND EMAIL TO mfpa-request@mfpa.org IF YOU WISH TO SEND REPRESENTATIVE(S) TO THIS MEETING. The meeting will be primarily a presentation format, with presentation of IS-650 and Troika API, and an overview of the MFPA organization. I will be also investigating a possible Birds of a Feather meeting with Salutation Consortium. -Raymond MFPA MEETING NOTICE -- TOKYO, JAPAN -- MAY 23, 1996 ***PRELIMINARY*** A one-day overview meeting is planned for Tokyo, Japan, on May 23, 1996. The site and arrangements are still not pinned down. However, since I was finding myself in Tokyo on other business, this will work well for everyone. If you are located in Japan or have associates that would like to attend this meeting, please let us know ASAP so that we can make the required arrangements. PLEASE SEND EMAIL TO mfpa-request@mfpa.org IF YOU WISH TO SEND REPRESENTATIVE(S) TO THIS MEETING. The meeting will be primarily a presentation format, with presentation of IS-650 and Troika API, and an overview of the MFPA organization. I will be also investigating a possible Birds of a Feather meeting with Salutation Consortium. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPA MEETING NOTICE -- TOKYO, JAPAN -- MAY 23, 1996 ***PRELIMINARY*** A one-day overview meeting is planned for Tokyo, Japan, on May 23, 1996. The site and arrangements are still not pinned down. However, since I was finding myself in Tokyo on other business, this will work well for everyone. If you are located in Japan or have associates that would like to attend this meeting, please let us know ASAP so that we can make the required arrangements. PLEASE SEND EMAIL TO mfpa-request@mfpa.org IF YOU WISH TO SEND REPRESENTATIVE(S) TO THIS MEETING. The meeting will be primarily a presentation format, with presentation of IS-650 and Troika API, and an overview of the MFPA organization. I will be also investigating a possible Birds of a Feather meeting with Salutation Consortium. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Regarding your comment: > The mib-2 reference therefore deals with USB, Firewire, Ethernet > 10BaseT 10Base2, as well as EIA232, IEEE1284, etc. You were referring to RFC-1573 "Evolution of the Interfaces Group of MIB-II", I believe. Here is the section of this file that seems relevant to the specific job of identifying the interface type: **** Quote **** IANAifType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifType object in the (updated) definition of MIB-II's ifTable. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@isi.edu). The relationship between the assignment of ifType values and of OIDs to particular media-specific MIBs is solely the purview of IANA and is subject to change without notice. Quite often, a media-specific MIB's OID-subtree assignment within MIB-II's 'transmission' subtree will be the same as its ifType value. However, in some circumstances this will not be the case, and implementors must not pre-assume any specific relationship between ifType values and transmission subtree OIDs." SYNTAX INTEGER { other(1), -- none of the following regular1822(2), hdh1822(3), ddnX25(4), rfc877x25(5), ethernetCsmacd(6), iso88023Csmacd(7), iso88024TokenBus(8), iso88025TokenRing(9), iso88026Man(10), starLan(11), proteon10Mbit(12), proteon80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), -- DS1/E1 (RFC 1406) e1(19), -- obsolete basicISDN(20), primaryISDN(21), propPointToPointSerial(22), -- proprietary serial ppp(23), softwareLoopback(24), eon(25), -- CLNP over IP (RFC 1070) ethernet3Mbit(26), nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- T-3 sip(31), -- SMDS frameRelay(32), -- DTE only rs232(33), para(34), -- parallel-port arcnet(35), -- arcnet arcnetPlus(36), -- arcnet plus atm(37), -- ATM cells miox25(38), sonet(39), -- SONET or SDH x25ple(40), iso88022llc(41), localTalk(42), smdsDxi(43), frameRelayService(44), -- Frame relay DCE v35(45), hssi(46), hippi(47), modem(48), -- Generic modem aal5(49), -- AAL5 over ATM sonetPath(50), sonetVT(51), smdsIcip(52), -- SMDS InterCarrier Interface propVirtual(53), -- proprietary virtual/internal propMultiplexor(54) -- proprietary multiplexing **** Unquote **** I am trying to map in the types we were discussing: USB (not included) Firewire IEEE-1394 (not included) Ethernet 10BaseT \ ethernetCsmacd(6) 10Base2 / EIA232 rs232(33) IEEE1284 para(34) Hmmm.... It seems that the ifTypes is a bit higher than the physical layer, and that there is some chance of needing more than one of the values. Do we need to extend this list? I didn't see any extensions in the ASSIGNED NUMBERS, (RFC-1700). -Raymond At 08:05 AM 4/25/96 PDT, Larry Masinter wrote: >Let me cut to the essential point: > >I think the MIME system of format identification >(application/postscript,version=2.0) is as capable as anything else >you might invent. It's a bit wordy, though, and you might be tempted >to invent something that's more compact, ("ADOBE|PS|2"). I'm game. I don't see all the various forms of printer languages defined, though. Somehow "Postscript" has the unusual position in the Internet community in this regard, if I'm not mistaken. Should I say: (application/HP-PCL,version=5E) for a file which is HP-PCL5E? I have tried to research this area, and I think it is perhaps the most important identification area. For my purposes, I am calling this ContentType. We have MediaType which describes the physical media that the ContentType is represented on. (I think this is the way the MIME group should view it as well. Here are the various ways this is handled in popular standards ISO-10175 DPA document-format (OBJECT IDENTIFIER) RFC-1759 PTR MIB prtInterpreterLangFamily + LangLevel + LangVersion LMO (Finishing) "Print File Format", LINEDATA, MIXED, MODCA BFT/T.434 content-type (OID/String) MIME content-type/ subtype (See details below) ISIS (Scanner API) OUTTYPE (STRING) T.30 G3 Fax DIS (53) [BFT] DIS (54) [DTM] DIS (55) [EDI] DIS (57) [BTM] DIS (59,60) Character Mode DIS (62) Mixed Mode DIS (65) Processable ... And I'm sure there are more. So, it is not clear that there is any single standard in use here. MIME is just one more group doing it's own thing. The Electronic Mail Assocation is advocating using BFT/T.434 and an OBJECT IDENTIFIER as an application body type. This OID approach seems to be the most extensible and certainly has support in many circles. It also has detractors, such as myself. I don't like it because I can't read it and easily tell what the hell it is. Therefore, I like the MIME approach. >However, I think interoperability with electronic mail and the World >Wide Web and netnews is an important goal. If you invent a more >compact representation, please don't be tempted to establish a >separate registry! So, I recommend not establishing a separate >registry, except, perhaps, a registry of "short abbreviations". I would love to embrace the MIME scheme. It seems a bit goofy because it has adopted a single print file format (Postscript) and no others. This seems to be the only major exception to the general architecture of the MIME ContentType naming. I see the following in the RFC-1700, assigned numbers: ****Quote**** MEDIA TYPES [RFC1521] specifies that Content Types, Content Subtypes, Character Sets, Access Types, and Conversion values for MIME mail will be assigned and listed by the IANA. Content Types and Subtypes -------------------------- Type Subtype Description Reference ---- ------- ----------- --------- text plain [RFC1521,NSB] richtext [RFC1521,NSB] tab-separated-values [Paul Lindner] multipart mixed [RFC1521,NSB] alternative [RFC1521,NSB] digest [RFC1521,NSB] parallel [RFC1521,NSB] appledouble [MacMime,Patrik Faltstrom] header-set [Dave Crocker] message rfc822 [RFC1521,NSB] partial [RFC1521,NSB] external-body [RFC1521,NSB] news [RFC 1036, Henry Spencer] application octet-stream [RFC1521,NSB] postscript [RFC1521,NSB] oda [RFC1521,NSB] atomicmail [atomicmail,NSB] andrew-inset [andrew-inset,NSB] slate [slate,terry crowley] wita [Wang Info Transfer,Larry Campbell] dec-dx [Digital Doc Trans, Larry Campbell] dca-rft [IBM Doc Content Arch, Larry Campbell] activemessage [Ehud Shapiro] rtf [Paul Lindner] applefile [MacMime,Patrik Faltstrom] mac-binhex40 [MacMime,Patrik Faltstrom] news-message-id [RFC1036, Henry Spencer] news-transmission [RFC1036, Henry Spencer] wordperfect5.1 [Paul Lindner] pdf [Paul Lindner] zip [Paul Lindner] macwriteii [Paul Lindner] msword [Paul Lindner] remote-printing [RFC1486,MTR] image jpeg [RFC1521,NSB] gif [RFC1521,NSB] ief Image Exchange Format [RFC1314] tiff Tag Image File Format [MTR] audio basic [RFC1521,NSB] video mpeg [RFC1521,NSB] quicktime [Paul Lindner] The "media-types" directory contains a subdirectory for each content type and each of those directories contains a file for each content subtype. |-application- |-audio------- |-image------- |-media-types-|-message----- |-multipart--- |-text-------- |-video------- URL = ftp://ftp.isi.edu/in-notes/iana/assignments/media-types **** UNQUOTE **** I don't see any other printer langauge other than Postscript. Should we add a bunch of printer languages to this list? I'm sure this is nice for Adobe, being the owner of the only printer language "sanctioned" by the IETF and MIME. So, although the MIME approach promises interoperability with Internet email and the WWW, I still don't know exactly how to format the string that you are suggesting for the numerous printer langauges already listed in RFC-1759. Can you help me? > >I said: > >>It's only when you have a live interactive connection that you might >>want to negotiate about precisely what version the recipient device >>might want optimally. > >and you replied: > >> Not True! I have to do it by telephone now or manually by email. email and >> other forms of communication and the memory available ALLOWS optimized >> transmissions. Your conclusion is based on one assumption: we know nothing >> about the recipient device in advance. It is perfectly reasonable to >> discover the capabilities of a recipient with a preliminary communication. >> This does not have to occur on a live interactive connection. In fact, if >> you are sending say Postscript and you know that it will take a long time to >> render if the recipient only takes Group 3 fax formats, then the live >> interactive telephone calls are typically terminated and the rendering is >> done off-line. > >I stand corrected. "a live interactive connection" => "the possibility >of interacting". It's only when you have the possibility of >interacting that you might want to negotiatiate about precisely what >version the recipient device might want optimally. MIME was originally >designed for the case where there was not going to be any interaction. >In that case, the main thing you can do is to try to restrict the >number of document formats that senders send, and require recipients >to accept the widest variety of document formats. Thank you. I still think that the limitation of NO INTERACTION is quite artificial. Granted, if you are broadcasting to kazillion addresses, it is not reasonable to know all the formats for each one, but there is also the possibility that there can be some memory of what was acceptable and perhaps some conversion capability on one end or the other as well. Your use of this assumption is based on the idea that transmission costs are zero. "We'll just include all formats in one large file, and then no matter who receives it, they will be able to use one of those formats". This just isn't reality when there is a cost for transmission. You have to settle on no more than a few formats. And if there are special cases, you want to record these cases so that you can be successful in the future. In fact, if the transmitter is paying for the transmission, he will be perfectly willing to perform preliminary communication with the receiver to discover which formats are acceptable. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ At 08:05 AM 4/25/96 PDT, Larry Masinter wrote: >Let me cut to the essential point: > >I think the MIME system of format identification >(application/postscript,version=2.0) is as capable as anything else >you might invent. It's a bit wordy, though, and you might be tempted >to invent something that's more compact, ("ADOBE|PS|2"). I'm game. I don't see all the various forms of printer languages defined, though. Somehow "Postscript" has the unusual position in the Internet community in this regard, if I'm not mistaken. Should I say: (application/HP-PCL,version=5E) for a file which is HP-PCL5E? I have tried to research this area, and I think it is perhaps the most important identification area. For my purposes, I am calling this ContentType. We have MediaType which describes the physical media that the ContentType is represented on. (I think this is the way the MIME group should view it as well. Here are the various ways this is handled in popular standards ISO-10175 DPA document-format (OBJECT IDENTIFIER) RFC-1759 PTR MIB prtInterpreterLangFamily + LangLevel + LangVersion LMO (Finishing) "Print File Format", LINEDATA, MIXED, MODCA BFT/T.434 content-type (OID/String) MIME content-type/ subtype (See details below) ISIS (Scanner API) OUTTYPE (STRING) T.30 G3 Fax DIS (53) [BFT] DIS (54) [DTM] DIS (55) [EDI] DIS (57) [BTM] DIS (59,60) Character Mode DIS (62) Mixed Mode DIS (65) Processable ... And I'm sure there are more. So, it is not clear that there is any single standard in use here. MIME is just one more group doing it's own thing. The Electronic Mail Assocation is advocating using BFT/T.434 and an OBJECT IDENTIFIER as an application body type. This OID approach seems to be the most extensible and certainly has support in many circles. It also has detractors, such as myself. I don't like it because I can't read it and easily tell what the hell it is. Therefore, I like the MIME approach. >However, I think interoperability with electronic mail and the World >Wide Web and netnews is an important goal. If you invent a more >compact representation, please don't be tempted to establish a >separate registry! So, I recommend not establishing a separate >registry, except, perhaps, a registry of "short abbreviations". I would love to embrace the MIME scheme. It seems a bit goofy because it has adopted a single print file format (Postscript) and no others. This seems to be the only major exception to the general architecture of the MIME ContentType naming. I see the following in the RFC-1700, assigned numbers: ****Quote**** MEDIA TYPES [RFC1521] specifies that Content Types, Content Subtypes, Character Sets, Access Types, and Conversion values for MIME mail will be assigned and listed by the IANA. Content Types and Subtypes -------------------------- Type Subtype Description Reference ---- ------- ----------- --------- text plain [RFC1521,NSB] richtext [RFC1521,NSB] tab-separated-values [Paul Lindner] multipart mixed [RFC1521,NSB] alternative [RFC1521,NSB] digest [RFC1521,NSB] parallel [RFC1521,NSB] appledouble [MacMime,Patrik Faltstrom] header-set [Dave Crocker] message rfc822 [RFC1521,NSB] partial [RFC1521,NSB] external-body [RFC1521,NSB] news [RFC 1036, Henry Spencer] application octet-stream [RFC1521,NSB] postscript [RFC1521,NSB] oda [RFC1521,NSB] atomicmail [atomicmail,NSB] andrew-inset [andrew-inset,NSB] slate [slate,terry crowley] wita [Wang Info Transfer,Larry Campbell] dec-dx [Digital Doc Trans, Larry Campbell] dca-rft [IBM Doc Content Arch, Larry Campbell] activemessage [Ehud Shapiro] rtf [Paul Lindner] applefile [MacMime,Patrik Faltstrom] mac-binhex40 [MacMime,Patrik Faltstrom] news-message-id [RFC1036, Henry Spencer] news-transmission [RFC1036, Henry Spencer] wordperfect5.1 [Paul Lindner] pdf [Paul Lindner] zip [Paul Lindner] macwriteii [Paul Lindner] msword [Paul Lindner] remote-printing [RFC1486,MTR] image jpeg [RFC1521,NSB] gif [RFC1521,NSB] ief Image Exchange Format [RFC1314] tiff Tag Image File Format [MTR] audio basic [RFC1521,NSB] video mpeg [RFC1521,NSB] quicktime [Paul Lindner] The "media-types" directory contains a subdirectory for each content type and each of those directories contains a file for each content subtype. |-application- |-audio------- |-image------- |-media-types-|-message----- |-multipart--- |-text-------- |-video------- URL = ftp://ftp.isi.edu/in-notes/iana/assignments/media-types **** UNQUOTE **** I don't see any other printer langauge other than Postscript. Should we add a bunch of printer languages to this list? I'm sure this is nice for Adobe, being the owner of the only printer language "sanctioned" by the IETF and MIME. So, although the MIME approach promises interoperability with Internet email and the WWW, I still don't know exactly how to format the string that you are suggesting for the numerous printer langauges already listed in RFC-1759. Can you help me? > >I said: > >>It's only when you have a live interactive connection that you might >>want to negotiate about precisely what version the recipient device >>might want optimally. > >and you replied: > >> Not True! I have to do it by telephone now or manually by email. email and >> other forms of communication and the memory available ALLOWS optimized >> transmissions. Your conclusion is based on one assumption: we know nothing >> about the recipient device in advance. It is perfectly reasonable to >> discover the capabilities of a recipient with a preliminary communication. >> This does not have to occur on a live interactive connection. In fact, if >> you are sending say Postscript and you know that it will take a long time to >> render if the recipient only takes Group 3 fax formats, then the live >> interactive telephone calls are typically terminated and the rendering is >> done off-line. > >I stand corrected. "a live interactive connection" => "the possibility >of interacting". It's only when you have the possibility of >interacting that you might want to negotiatiate about precisely what >version the recipient device might want optimally. MIME was originally >designed for the case where there was not going to be any interaction. >In that case, the main thing you can do is to try to restrict the >number of document formats that senders send, and require recipients >to accept the widest variety of document formats. Thank you. I still think that the limitation of NO INTERACTION is quite artificial. Granted, if you are broadcasting to kazillion addresses, it is not reasonable to know all the formats for each one, but there is also the possibility that there can be some memory of what was acceptable and perhaps some conversion capability on one end or the other as well. Your use of this assumption is based on the idea that transmission costs are zero. "We'll just include all formats in one large file, and then no matter who receives it, they will be able to use one of those formats". This just isn't reality when there is a cost for transmission. You have to settle on no more than a few formats. And if there are special cases, you want to record these cases so that you can be successful in the future. In fact, if the transmitter is paying for the transmission, he will be perfectly willing to perform preliminary communication with the receiver to discover which formats are acceptable. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Regarding your comment: > The mib-2 reference therefore deals with USB, Firewire, Ethernet > 10BaseT 10Base2, as well as EIA232, IEEE1284, etc. You were referring to RFC-1573 "Evolution of the Interfaces Group of MIB-II", I believe. Here is the section of this file that seems relevant to the specific job of identifying the interface type: **** Quote **** IANAifType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifType object in the (updated) definition of MIB-II's ifTable. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@isi.edu). The relationship between the assignment of ifType values and of OIDs to particular media-specific MIBs is solely the purview of IANA and is subject to change without notice. Quite often, a media-specific MIB's OID-subtree assignment within MIB-II's 'transmission' subtree will be the same as its ifType value. However, in some circumstances this will not be the case, and implementors must not pre-assume any specific relationship between ifType values and transmission subtree OIDs." SYNTAX INTEGER { other(1), -- none of the following regular1822(2), hdh1822(3), ddnX25(4), rfc877x25(5), ethernetCsmacd(6), iso88023Csmacd(7), iso88024TokenBus(8), iso88025TokenRing(9), iso88026Man(10), starLan(11), proteon10Mbit(12), proteon80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), -- DS1/E1 (RFC 1406) e1(19), -- obsolete basicISDN(20), primaryISDN(21), propPointToPointSerial(22), -- proprietary serial ppp(23), softwareLoopback(24), eon(25), -- CLNP over IP (RFC 1070) ethernet3Mbit(26), nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- T-3 sip(31), -- SMDS frameRelay(32), -- DTE only rs232(33), para(34), -- parallel-port arcnet(35), -- arcnet arcnetPlus(36), -- arcnet plus atm(37), -- ATM cells miox25(38), sonet(39), -- SONET or SDH x25ple(40), iso88022llc(41), localTalk(42), smdsDxi(43), frameRelayService(44), -- Frame relay DCE v35(45), hssi(46), hippi(47), modem(48), -- Generic modem aal5(49), -- AAL5 over ATM sonetPath(50), sonetVT(51), smdsIcip(52), -- SMDS InterCarrier Interface propVirtual(53), -- proprietary virtual/internal propMultiplexor(54) -- proprietary multiplexing **** Unquote **** I am trying to map in the types we were discussing: USB (not included) Firewire IEEE-1394 (not included) Ethernet 10BaseT \ ethernetCsmacd(6) 10Base2 / EIA232 rs232(33) IEEE1284 para(34) Hmmm.... It seems that the ifTypes is a bit higher than the physical layer, and that there is some chance of needing more than one of the values. Do we need to extend this list? I didn't see any extensions in the ASSIGNED NUMBERS, (RFC-1700). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Regarding your comment: > The mib-2 reference therefore deals with USB, Firewire, Ethernet > 10BaseT 10Base2, as well as EIA232, IEEE1284, etc. You were referring to RFC-1573 "Evolution of the Interfaces Group of MIB-II", I believe. Here is the section of this file that seems relevant to the specific job of identifying the interface type: **** Quote **** IANAifType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifType object in the (updated) definition of MIB-II's ifTable. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@isi.edu). The relationship between the assignment of ifType values and of OIDs to particular media-specific MIBs is solely the purview of IANA and is subject to change without notice. Quite often, a media-specific MIB's OID-subtree assignment within MIB-II's 'transmission' subtree will be the same as its ifType value. However, in some circumstances this will not be the case, and implementors must not pre-assume any specific relationship between ifType values and transmission subtree OIDs." SYNTAX INTEGER { other(1), -- none of the following regular1822(2), hdh1822(3), ddnX25(4), rfc877x25(5), ethernetCsmacd(6), iso88023Csmacd(7), iso88024TokenBus(8), iso88025TokenRing(9), iso88026Man(10), starLan(11), proteon10Mbit(12), proteon80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), -- DS1/E1 (RFC 1406) e1(19), -- obsolete basicISDN(20), primaryISDN(21), propPointToPointSerial(22), -- proprietary serial ppp(23), softwareLoopback(24), eon(25), -- CLNP over IP (RFC 1070) ethernet3Mbit(26), nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- T-3 sip(31), -- SMDS frameRelay(32), -- DTE only rs232(33), para(34), -- parallel-port arcnet(35), -- arcnet arcnetPlus(36), -- arcnet plus atm(37), -- ATM cells miox25(38), sonet(39), -- SONET or SDH x25ple(40), iso88022llc(41), localTalk(42), smdsDxi(43), frameRelayService(44), -- Frame relay DCE v35(45), hssi(46), hippi(47), modem(48), -- Generic modem aal5(49), -- AAL5 over ATM sonetPath(50), sonetVT(51), smdsIcip(52), -- SMDS InterCarrier Interface propVirtual(53), -- proprietary virtual/internal propMultiplexor(54) -- proprietary multiplexing **** Unquote **** I am trying to map in the types we were discussing: USB (not included) Firewire IEEE-1394 (not included) Ethernet 10BaseT \ ethernetCsmacd(6) 10Base2 / EIA232 rs232(33) IEEE1284 para(34) Hmmm.... It seems that the ifTypes is a bit higher than the physical layer, and that there is some chance of needing more than one of the values. Do we need to extend this list? I didn't see any extensions in the ASSIGNED NUMBERS, (RFC-1700). -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Folks: The Troika API is firming up, at least for the "Lower" layers! I am much happier about this current version. Please disregard revision 0.4 at this point and get Version 0.5. There are some short examples at the end that should help you understand the idea, at least for the MF... layer interface. It is at URL: ftp://ftp.cts.com/pub/MFPA/troika05.doz This is WinWord 6.0, PKZIPPED using encryption. Please use the password supplied previously. If you need the password, please contact MFPA headquarters at 619-447-1127 or 800-603-MFPA. Enjoy! -Raymond Have you forgotten to complete your MFPA survey? PLEASE DO IT NOW! If you are an MFPA member, this is one of the "benefits" of being a member, so let's make it valuable... -Raymond Have you forgotten to complete your MFPA survey? PLEASE DO IT NOW! If you are an MFPA member, this is one of the "benefits" of being a member, so let's make it valuable... -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Folks: The Troika API is firming up, at least for the "Lower" layers! I am much happier about this current version. Please disregard revision 0.4 at this point and get Version 0.5. There are some short examples at the end that should help you understand the idea, at least for the MF... layer interface. It is at URL: ftp://ftp.cts.com/pub/MFPA/troika05.doz This is WinWord 6.0, PKZIPPED using encryption. Please use the password supplied previously. If you need the password, please contact MFPA headquarters at 619-447-1127 or 800-603-MFPA. Enjoy! -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ You have seen the press release for IOC'96, and already we have many inquiries. For those of you who attended last year, you know this is a high-quality conference which promises to be even better this year. I am putting together the content of the conference now. If you want to participant in terms of presenting, please contact me SOON. ***-->Don't Delay<--*** Some "slow" companies last year learned that the space for making presentations fills up fast. This year, the conference will be slightly longer, with an additional 1/2 day of sessions in the morning of the first day in cooperation with TIA. So this will be a standards briefing on related communication standards. We will have more networking time this year too, so if you want to make contacts and find new business or are looking for product opportunities, this is the place for you.... There are many ways to participate: Attend Make a presentation Exhibit (limited booths at dynamite prices, so don't delay!) Sponsor breaks and meals and more! MARK YOUR CALENDARS... Oct 21,22,23, 1996. Contact me now if you have good material to present at this conference. -Raymond You have seen the press release for IOC'96, and already we have many inquiries. For those of you who attended last year, you know this is a high-quality conference which promises to be even better this year. I am putting together the content of the conference now. If you want to participant in terms of presenting, please contact me SOON. ***-->Don't Delay<--*** Some "slow" companies last year learned that the space for making presentations fills up fast. This year, the conference will be slightly longer, with an additional 1/2 day of sessions in the morning of the first day in cooperation with TIA. So this will be a standards briefing on related communication standards. We will have more networking time this year too, so if you want to make contacts and find new business or are looking for product opportunities, this is the place for you.... There are many ways to participate: Attend Make a presentation Exhibit (limited booths at dynamite prices, so don't delay!) Sponsor breaks and meals and more! MARK YOUR CALENDARS... Oct 21,22,23, 1996. Contact me now if you have good material to present at this conference. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ FYI: To support continued work on IS-650 to allow it to be refined as an "industry standard" or as a revision of an interim standard, the project number PN-3756 has been assigned. -Raymond FYI: To support continued work on IS-650 to allow it to be refined as an "industry standard" or as a revision of an interim standard, the project number PN-3756 has been assigned. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hello: The MFPA is holding a combo technical/marketing meeting on 5/1-2/1996 in San Diego, CA, at the Embassy Suites Hotel. A meeting notice with the details of the meeting site has already been distributed. (See MN960501.xxx at ftp site if you don't have it). You can obtain a detailed meeting agenda by retrieving the following document: ftp://ftp.cts.com/pub/MFPA/ma960501.doc This is WinWord 6.0 (yes, we have upgraded since I am not hearing of any complaints. Please let me know if this is not easily obtainable by all.) A rough agenda is as follows. Please retrieve the (3 page) document for gory detail. (Note the document is not actually completely done because many of the referenced document numbers were not defined when I loaded it onto the ftp site.) DAY 1, 5/1/1996, MFPA Working Group =================================== Administration, sign-in, introductions, etc. TIA PN-3756: refinement of MFPI-1 Troika-1 DAY 2, 5/2/1996, MFPA General Meeting ===================================== Administration, sign-in, introductions, etc. Review Meeting report from last meeting Director member services report Executive Council Report Technical Coordination MFPA Working Group Report MFPA position on MFPI-1 Troika progression Salutatation Consortium IEEE-1284.3/4 Printer Working Group (PWG) TR29/ITU (PN-3756 and BFT work) AIIM (Scanner MIB) USB IEEE-1394 Interdomain Job Submission Enhanced Facsimile and Extended Negotiations Marketing/Awareness Issues Tokyo Meeting Member Survey Levels of Service COMDEX Spring plans WWW Site Report, Support technologies page IOC'96 Conference (** Important) MFPA Marketing Image (new logo, etc.) MFP Market Name -Raymond Hello: The MFPA is holding a combo technical/marketing meeting on 5/1-2/1996 in San Diego, CA, at the Embassy Suites Hotel. A meeting notice with the details of the meeting site has already been distributed. (See MN960501.xxx at ftp site if you don't have it). You can obtain a detailed meeting agenda by retrieving the following document: ftp://ftp.cts.com/pub/MFPA/ma960501.doc This is WinWord 6.0 (yes, we have upgraded since I am not hearing of any complaints. Please let me know if this is not easily obtainable by all.) A rough agenda is as follows. Please retrieve the (3 page) document for gory detail. (Note the document is not actually completely done because many of the referenced document numbers were not defined when I loaded it onto the ftp site.) DAY 1, 5/1/1996, MFPA Working Group =================================== Administration, sign-in, introductions, etc. TIA PN-3756: refinement of MFPI-1 Troika-1 DAY 2, 5/2/1996, MFPA General Meeting ===================================== Administration, sign-in, introductions, etc. Review Meeting report from last meeting Director member services report Executive Council Report Technical Coordination MFPA Working Group Report MFPA position on MFPI-1 Troika progression Salutatation Consortium IEEE-1284.3/4 Printer Working Group (PWG) TR29/ITU (PN-3756 and BFT work) AIIM (Scanner MIB) USB IEEE-1394 Interdomain Job Submission Enhanced Facsimile and Extended Negotiations Marketing/Awareness Issues Tokyo Meeting Member Survey Levels of Service COMDEX Spring plans WWW Site Report, Support technologies page IOC'96 Conference (** Important) MFPA Marketing Image (new logo, etc.) MFP Market Name -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hello: The MFPA is holding a combo technical/marketing meeting on 5/1-2/1996 in San Diego, CA, at the Embassy Suites Hotel. A meeting notice with the details of the meeting site has already been distributed. (See MN960501.xxx at ftp site if you don't have it). You can obtain a detailed meeting agenda by retrieving the following document: ftp://ftp.cts.com/pub/MFPA/ma960501.doc This is WinWord 6.0 (yes, we have upgraded since I am not hearing of any complaints. Please let me know if this is not easily obtainable by all.) A rough agenda is as follows. Please retrieve the (3 page) document for gory detail. (Note the document is not actually completely done because many of the referenced document numbers were not defined when I loaded it onto the ftp site.) DAY 1, 5/1/1996, MFPA Working Group =================================== Administration, sign-in, introductions, etc. TIA PN-3756: refinement of MFPI-1 Troika-1 DAY 2, 5/2/1996, MFPA General Meeting ===================================== Administration, sign-in, introductions, etc. Review Meeting report from last meeting Director member services report Executive Council Report Technical Coordination MFPA Working Group Report MFPA position on MFPI-1 Troika progression Salutatation Consortium IEEE-1284.3/4 Printer Working Group (PWG) TR29/ITU (PN-3756 and BFT work) AIIM (Scanner MIB) USB IEEE-1394 Interdomain Job Submission Enhanced Facsimile and Extended Negotiations Marketing/Awareness Issues Tokyo Meeting Member Survey Levels of Service COMDEX Spring plans WWW Site Report, Support technologies page IOC'96 Conference (** Important) MFPA Marketing Image (new logo, etc.) MFP Market Name -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Raymond, Yes, the interface is defined by rfc1573 (or the subsequent number of the 'evolution' document.) As indicated in your extract, this allows interfaces to be added using IANA as the registry. Do we need to extend this list? Yes, there may be need for interested parties to add more interfaces as the need arises. In response to that fact that you didn't see any extensions in the ASSIGNED NUMBERS (RFC-1700), as Randy Turner has indicated, rfc1700 is a 'snapshot in time' of what was in the registry. The current IANA registry information can be found at ftp://venera.isi.edu/in-notes/iana/assignments (although I see no additional interfaces yet). With respect to "the ifTypes is a bit higher than the physical layer, and that there is some chance of needing more than one of the values.", rfc1573 indicates that not all levels must be indicated, and obviously, if being used with rfc1759, the appropriate lowest level would be used. If there is a need to know intermediate layers, the currently-being-considered Printer mib Channels group reference to the Network Services Monitoring MIB (rfc 1565) might be just the ticket. But perhaps more germane is the fact that the PWG did not particularly want to use the interfaces table, or the Host resources MIB. Certainly, the group could do a better job identifying interfaces, memory, and other peripheral devices attached to a printer. But the group was seeking to get a definition of printer device characteristics standardized by an organization that dealt with networking. And the cultures were different. The PWG decided it was better to conform as best could and be accepted than to have things the way we wanted but be divergent from the culture in the environment in which we wanted to bring printers. As might be expected, some of the concessions seem to work, while others leave holes that must be filled by other means. But we are working on something that both printer people and network people can recognize as not too alien from that to which they are accustomed. Even in technical fields, the vagaries of human interaction often have more bearing on the success of a standard than technical conciseness. Raymond, Yes, the interface is defined by rfc1573 (or the subsequent number of the 'evolution' document.) As indicated in your extract, this allows interfaces to be added using IANA as the registry. Do we need to extend this list? Yes, there may be need for interested parties to add more interfaces as the need arises. In response to that fact that you didn't see any extensions in the ASSIGNED NUMBERS (RFC-1700), as Randy Turner has indicated, rfc1700 is a 'snapshot in time' of what was in the registry. The current IANA registry information can be found at ftp://venera.isi.edu/in-notes/iana/assignments (although I see no additional interfaces yet). With respect to "the ifTypes is a bit higher than the physical layer, and that there is some chance of needing more than one of the values.", rfc1573 indicates that not all levels must be indicated, and obviously, if being used with rfc1759, the appropriate lowest level would be used. If there is a need to know intermediate layers, the currently-being-considered Printer mib Channels group reference to the Network Services Monitoring MIB (rfc 1565) might be just the ticket. But perhaps more germane is the fact that the PWG did not particularly want to use the interfaces table, or the Host resources MIB. Certainly, the group could do a better job identifying interfaces, memory, and other peripheral devices attached to a printer. But the group was seeking to get a definition of printer device characteristics standardized by an organization that dealt with networking. And the cultures were different. The PWG decided it was better to conform as best could and be accepted than to have things the way we wanted but be divergent from the culture in the environment in which we wanted to bring printers. As might be expected, some of the concessions seem to work, while others leave holes that must be filled by other means. But we are working on something that both printer people and network people can recognize as not too alien from that to which they are accustomed. Even in technical fields, the vagaries of human interaction often have more bearing on the success of a standard than technical conciseness. Ray Lutz asked that I forward a copy of our press release to you. Bobby Amirshahi TIA Communications Asst. (703) 907-7723 ------------------------------------------------------------- Uuencoded File Attachment: RAYLUTZ.WPD ------------------------------------------------------------- Attachment Converted: Z:\MAIL\ATTACH\RAYLUTZ.WPD Raymond, Yes, the interface is defined by rfc1573 (or the subsequent number of the 'evolution' document.) As indicated in your extract, this allows interfaces to be added using IANA as the registry. Do we need to extend this list? Yes, there may be need for interested parties to add more interfaces as the need arises. In response to that fact that you didn't see any extensions in the ASSIGNED NUMBERS (RFC-1700), as Randy Turner has indicated, rfc1700 is a 'snapshot in time' of what was in the registry. The current IANA registry information can be found at ftp://venera.isi.edu/in-notes/iana/assignments (although I see no additional interfaces yet). With respect to "the ifTypes is a bit higher than the physical layer, and that there is some chance of needing more than one of the values.", rfc1573 indicates that not all levels must be indicated, and obviously, if being used with rfc1759, the appropriate lowest level would be used. If there is a need to know intermediate layers, the currently-being-considered Printer mib Channels group reference to the Network Services Monitoring MIB (rfc 1565) might be just the ticket. But perhaps more germane is the fact that the PWG did not particularly want to use the interfaces table, or the Host resources MIB. Certainly, the group could do a better job identifying interfaces, memory, and other peripheral devices attached to a printer. But the group was seeking to get a definition of printer device characteristics standardized by an organization that dealt with networking. And the cultures were different. The PWG decided it was better to conform as best could and be accepted than to have things the way we wanted but be divergent from the culture in the environment in which we wanted to bring printers. As might be expected, some of the concessions seem to work, while others leave holes that must be filled by other means. But we are working on something that both printer people and network people can recognize as not too alien from that to which they are accustomed. Even in technical fields, the vagaries of human interaction often have more bearing on the success of a standard than technical conciseness. Bill: Your point is well taken. I have reviewed the current assignments and the interfaces group of MIB-II. It is not much better. I still think it would have been better to use "none" in RFC-1759 if there was no additional layer between the layers already presented in MIB-II instead of making new definitions for things like RS-232. I understand now why the channels group is such a hodge-podge. It reflects the hodge-podge of MIB-II. Our internal policy will be to use MIB-II enums unless the channel cannot be adequately expressed. To say RS-232 twice is worthless. Also, I think I still have some basis for suggesting that the entries in the Channels group of RFC-1759 can be more unambiguously specified. I like the registration process used by MIME "Media-Types". See Here is an extraction of the significant portion of that document: **** Quote 4.2.4. Canonicalization and Format Requirements All registered media types must employ a single, canonical data format, regardless of registration tree. A precise and openly available specification of the format of each media type is required for all types registered in the IETF tree and must at a minimum be referenced by, if it isn't actually included in, the media type registration proposal itself. The specifications of format and processing particulars may or may not be publically available for media types registered in the vendor tree, and such registration proposals are explicitly permitted to include only a specification of which software and version produce or process such media types. References to or inclusion of format specifications in registration proposals is encouraged but not required. Format specifications are still required for registration in the personal tree, but may be either published as RFCs or otherwise deposited with IANA. The deposited specifications will meet the same criteria as those required to register a well-known TCP port and, in particular, need not be made public. Some media types involve the use of patented technology. The registration of media types involving patented technology is specifically permitted. However, the restrictions set forth in RFC 1602 on the use of patented technology in standards- track protocols must be respected when the specification of a media type is part of a standards-track protocol. **** Unquote So, it states that for vendor specific formats, a formal specification is not mandatory, but desired. The specification of the software that produces or processes the format is required. I would go along with this idea, and I think the PWG should consider this reasonable, at least for the PrtInterpreterLang part. For the Channels group, which is also loosely specified, I would hope that similar criteria can be established. It is most simple to adopt the MIME registration process for those as well, or for that matter, anything else that requires some public review. -Raymond At 10:41 AM 4/29/96 -0400, Bill Wagner wrote: >Raymond, > > Yes, the interface is defined by rfc1573 (or the subsequent number of > the 'evolution' document.) As indicated in your extract, this allows > interfaces to be added using IANA as the registry. Do we need to > extend this list? Yes, there may be need for interested parties to > add more interfaces as the need arises. > > > In response to that fact that you didn't see any extensions in the > ASSIGNED NUMBERS (RFC-1700), as Randy Turner has indicated, rfc1700 > is a 'snapshot in time' of what was in the registry. The current IANA > registry information can be found at > ftp://venera.isi.edu/in-notes/iana/assignments > (although I see no additional interfaces yet). > > With respect to "the ifTypes is a bit higher than the physical layer, > and that there is some chance of needing more than one of the > values.", rfc1573 indicates that not all levels must be indicated, and > obviously, if being used with rfc1759, the appropriate lowest level > would be used. If there is a need to know intermediate layers, the > currently-being-considered Printer mib Channels group reference to the > Network Services Monitoring MIB (rfc 1565) might be just the ticket. > > But perhaps more germane is the fact that the PWG did not particularly > want to use the interfaces table, or the Host resources MIB. > Certainly, the group could do a better job identifying interfaces, > memory, and other peripheral devices attached to a printer. But the > group was seeking to get a definition of printer device > characteristics standardized by an organization that dealt with > networking. And the cultures were different. The PWG decided it was > better to conform as best could and be accepted than to have things > the way we wanted but be divergent from the culture in the environment > in which we wanted to bring printers. As might be expected, some of > the concessions seem to work, while others leave holes that must be > filled by other means. But we are working on something that both > printer people and network people can recognize as not too alien from > that to which they are accustomed. > > Even in technical fields, the vagaries of human interaction often have > more bearing on the success of a standard than technical conciseness. > > > > > > Bill: Your point is well taken. I have reviewed the current assignments and the interfaces group of MIB-II. It is not much better. I still think it would have been better to use "none" in RFC-1759 if there was no additional layer between the layers already presented in MIB-II instead of making new definitions for things like RS-232. I understand now why the channels group is such a hodge-podge. It reflects the hodge-podge of MIB-II. Our internal policy will be to use MIB-II enums unless the channel cannot be adequately expressed. To say RS-232 twice is worthless. Also, I think I still have some basis for suggesting that the entries in the Channels group of RFC-1759 can be more unambiguously specified. I like the registration process used by MIME "Media-Types". See Here is an extraction of the significant portion of that document: **** Quote 4.2.4. Canonicalization and Format Requirements All registered media types must employ a single, canonical data format, regardless of registration tree. A precise and openly available specification of the format of each media type is required for all types registered in the IETF tree and must at a minimum be referenced by, if it isn't actually included in, the media type registration proposal itself. The specifications of format and processing particulars may or may not be publically available for media types registered in the vendor tree, and such registration proposals are explicitly permitted to include only a specification of which software and version produce or process such media types. References to or inclusion of format specifications in registration proposals is encouraged but not required. Format specifications are still required for registration in the personal tree, but may be either published as RFCs or otherwise deposited with IANA. The deposited specifications will meet the same criteria as those required to register a well-known TCP port and, in particular, need not be made public. Some media types involve the use of patented technology. The registration of media types involving patented technology is specifically permitted. However, the restrictions set forth in RFC 1602 on the use of patented technology in standards- track protocols must be respected when the specification of a media type is part of a standards-track protocol. **** Unquote So, it states that for vendor specific formats, a formal specification is not mandatory, but desired. The specification of the software that produces or processes the format is required. I would go along with this idea, and I think the PWG should consider this reasonable, at least for the PrtInterpreterLang part. For the Channels group, which is also loosely specified, I would hope that similar criteria can be established. It is most simple to adopt the MIME registration process for those as well, or for that matter, anything else that requires some public review. -Raymond At 10:41 AM 4/29/96 -0400, Bill Wagner wrote: >Raymond, > > Yes, the interface is defined by rfc1573 (or the subsequent number of > the 'evolution' document.) As indicated in your extract, this allows > interfaces to be added using IANA as the registry. Do we need to > extend this list? Yes, there may be need for interested parties to > add more interfaces as the need arises. > > > In response to that fact that you didn't see any extensions in the > ASSIGNED NUMBERS (RFC-1700), as Randy Turner has indicated, rfc1700 > is a 'snapshot in time' of what was in the registry. The current IANA > registry information can be found at > ftp://venera.isi.edu/in-notes/iana/assignments > (although I see no additional interfaces yet). > > With respect to "the ifTypes is a bit higher than the physical layer, > and that there is some chance of needing more than one of the > values.", rfc1573 indicates that not all levels must be indicated, and > obviously, if being used with rfc1759, the appropriate lowest level > would be used. If there is a need to know intermediate layers, the > currently-being-considered Printer mib Channels group reference to the > Network Services Monitoring MIB (rfc 1565) might be just the ticket. > > But perhaps more germane is the fact that the PWG did not particularly > want to use the interfaces table, or the Host resources MIB. > Certainly, the group could do a better job identifying interfaces, > memory, and other peripheral devices attached to a printer. But the > group was seeking to get a definition of printer device > characteristics standardized by an organization that dealt with > networking. And the cultures were different. The PWG decided it was > better to conform as best could and be accepted than to have things > the way we wanted but be divergent from the culture in the environment > in which we wanted to bring printers. As might be expected, some of > the concessions seem to work, while others leave holes that must be > filled by other means. But we are working on something that both > printer people and network people can recognize as not too alien from > that to which they are accustomed. > > Even in technical fields, the vagaries of human interaction often have > more bearing on the success of a standard than technical conciseness. > > > > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bill: Your point is well taken. I have reviewed the current assignments and the interfaces group of MIB-II. It is not much better. I still think it would have been better to use "none" in RFC-1759 if there was no additional layer between the layers already presented in MIB-II instead of making new definitions for things like RS-232. I understand now why the channels group is such a hodge-podge. It reflects the hodge-podge of MIB-II. Our internal policy will be to use MIB-II enums unless the channel cannot be adequately expressed. To say RS-232 twice is worthless. Also, I think I still have some basis for suggesting that the entries in the Channels group of RFC-1759 can be more unambiguously specified. I like the registration process used by MIME "Media-Types". See Here is an extraction of the significant portion of that document: **** Quote 4.2.4. Canonicalization and Format Requirements All registered media types must employ a single, canonical data format, regardless of registration tree. A precise and openly available specification of the format of each media type is required for all types registered in the IETF tree and must at a minimum be referenced by, if it isn't actually included in, the media type registration proposal itself. The specifications of format and processing particulars may or may not be publically available for media types registered in the vendor tree, and such registration proposals are explicitly permitted to include only a specification of which software and version produce or process such media types. References to or inclusion of format specifications in registration proposals is encouraged but not required. Format specifications are still required for registration in the personal tree, but may be either published as RFCs or otherwise deposited with IANA. The deposited specifications will meet the same criteria as those required to register a well-known TCP port and, in particular, need not be made public. Some media types involve the use of patented technology. The registration of media types involving patented technology is specifically permitted. However, the restrictions set forth in RFC 1602 on the use of patented technology in standards- track protocols must be respected when the specification of a media type is part of a standards-track protocol. **** Unquote So, it states that for vendor specific formats, a formal specification is not mandatory, but desired. The specification of the software that produces or processes the format is required. I would go along with this idea, and I think the PWG should consider this reasonable, at least for the PrtInterpreterLang part. For the Channels group, which is also loosely specified, I would hope that similar criteria can be established. It is most simple to adopt the MIME registration process for those as well, or for that matter, anything else that requires some public review. -Raymond At 10:41 AM 4/29/96 -0400, Bill Wagner wrote: >Raymond, > > Yes, the interface is defined by rfc1573 (or the subsequent number of > the 'evolution' document.) As indicated in your extract, this allows > interfaces to be added using IANA as the registry. Do we need to > extend this list? Yes, there may be need for interested parties to > add more interfaces as the need arises. > > > In response to that fact that you didn't see any extensions in the > ASSIGNED NUMBERS (RFC-1700), as Randy Turner has indicated, rfc1700 > is a 'snapshot in time' of what was in the registry. The current IANA > registry information can be found at > ftp://venera.isi.edu/in-notes/iana/assignments > (although I see no additional interfaces yet). > > With respect to "the ifTypes is a bit higher than the physical layer, > and that there is some chance of needing more than one of the > values.", rfc1573 indicates that not all levels must be indicated, and > obviously, if being used with rfc1759, the appropriate lowest level > would be used. If there is a need to know intermediate layers, the > currently-being-considered Printer mib Channels group reference to the > Network Services Monitoring MIB (rfc 1565) might be just the ticket. > > But perhaps more germane is the fact that the PWG did not particularly > want to use the interfaces table, or the Host resources MIB. > Certainly, the group could do a better job identifying interfaces, > memory, and other peripheral devices attached to a printer. But the > group was seeking to get a definition of printer device > characteristics standardized by an organization that dealt with > networking. And the cultures were different. The PWG decided it was > better to conform as best could and be accepted than to have things > the way we wanted but be divergent from the culture in the environment > in which we wanted to bring printers. As might be expected, some of > the concessions seem to work, while others leave holes that must be > filled by other means. But we are working on something that both > printer people and network people can recognize as not too alien from > that to which they are accustomed. > > Even in technical fields, the vagaries of human interaction often have > more bearing on the success of a standard than technical conciseness. > > > > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ CONTACT: SHARON GRACE (703) 907-7721 FOR IMMEDIATE RELEASE: APRIL 12, 1996 TIA AND MFPA DEVELOP MULTIFUNCTION PERIPHERAL INTERFACE STANDARD Arlington, VA -- The Telecommunications Industry Association (TIA) has published TIA/EIA/IS (Interim Standard)-650, "Multifunction Peripheral Interface Standard (MFPI) Level 1," in association with the Multifunction Periperhal Association (MFPA). This standard defines an interface between a host computer and Multifunction Peripheral (MFP). A typical MFP is comprised of a scanner, printer, fax-data-voice modem, operator console and other subsystems. Raymond Lutz, executive council chair of the MFPA, vice chair of TIA TR-29.2 engineering committee and editor of the standard, comments, "MFPI-1 is the first of four levels which will allow such MFP devices to be cost-effectively controlled by the host computer or network, and allow dial-up devices to accept high-level printing and document processing instructions from the local site. This interim standard is now undergoing final revisions for submission as an industry standard later this year. Also, Levels 2-4 are being addressed in other projects within TIA and MFPA, as well as other standards organizations. The MFPI-1 standard has actually been under trial use for over one year, and real implementations are now being seen in the market, and promises to be a major enabling technology for the MFP area." The TIA/EIA/IS-650 Interim Standard can be obtained from Global Engineering Documents at (800) 854-7179. MFPA is a trade association specializing in the Multifunction Peripheral application area, and it composed of over 30 companies producing MFP product or contributing technologies TIA is a full-service national trade organization with membership of 600 large and small companies which provide communications and information technology products, materials, systems, distribution services and professional services in the United States and countries around the world. TIA represents the telecommunications industry in association with the Electronic Industries Association. ### EDITORS: Please note that information regarding the Telecommunications Industry Association is available via TIA s World Wide Web site at http://www.industry.net/tia P.A. Release 96-22 04.12.96 Dear Mike: Recently I sent you a message requesting some detail with respect to harmonizing CFP and MFPI. Since I'm sure you want to cooperate with this effort, I'm guessing that you have been studying the details of this request so that you can provide a technical contribution for our working group meeting. Can you give me an update on the status of this request? Cheers, -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Dear Mike: Recently I sent you a message requesting some detail with respect to harmonizing CFP and MFPI. Since I'm sure you want to cooperate with this effort, I'm guessing that you have been studying the details of this request so that you can provide a technical contribution for our working group meeting. Can you give me an update on the status of this request? Cheers, -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hello: Sorry about the last minute transmission of this file. If you are coming to the meeting, we will have hard-copies of these as well. You may access the newest draft of MFPI-1, Version 5.4 as: URL ftp://ftp.cts.com/pub/MFPA/is650_54.doz <-- draft w/revisions URL ftp://ftp.cts.com/pub/MFPA/650chg54.doc <-- Changes document The draft is password protected; The changes document is not password protected. Both documents are WinWord 6.0. Let me know if you have any problem accessing these. EVEN IF YOU CAN'T ATTEND THE MEETING, PLEASE REVIEW THESE DOCUMENTS AND PROVIDE TECHNICAL FEEDBACK. TECHNICAL CHANGES ARE PROPOSED THAT MAY AFFECT YOUR CURRENT IMPLEMENTATIONS. The changes document includes information on all changes since IS-650. -Raymond Hello: Sorry about the last minute transmission of this file. If you are coming to the meeting, we will have hard-copies of these as well. You may access the newest draft of MFPI-1, Version 5.4 as: URL ftp://ftp.cts.com/pub/MFPA/is650_54.doz <-- draft w/revisions URL ftp://ftp.cts.com/pub/MFPA/650chg54.doc <-- Changes document The draft is password protected; The changes document is not password protected. Both documents are WinWord 6.0. Let me know if you have any problem accessing these. EVEN IF YOU CAN'T ATTEND THE MEETING, PLEASE REVIEW THESE DOCUMENTS AND PROVIDE TECHNICAL FEEDBACK. TECHNICAL CHANGES ARE PROPOSED THAT MAY AFFECT YOUR CURRENT IMPLEMENTATIONS. The changes document includes information on all changes since IS-650. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Apologies for posting my status check out to the world. Unintended. Poked MFPA address from MFPA Home Page and didn't expect it to reflect. FYI -Raymond >Return-Path: >Date: Tue, 23 Apr 96 13:30 EDT >From: jkm@underscore.com (JK Martin) >To: raylutz@cognisys.com >Subject: MFPA interest in SENSE >Cc: jds@underscore.com, jkm@underscore.com >X-UIDL: 830323792.003 > >Ray, > >It's good to see that you're interested in SENSE. Let me see if I can >answer/address some of your questions/comments. > >Yes, SENSE is designed to be a general purpose network service. While >it is not explicitly and/or exclusively tied to printers, the design >goals of SENSE are such that printer-related event problems are used >as the primary target application problem domain; however, as you well >know, the kinds of events emanating from printers are relatively generic >across many other application problem domains, so SENSE should be quite >applicable for non-printer applications as well. > >Is the PWG the best home for SENSE? Maybe there are better "umbrellas" >to be found, but right now I personally choose to stay with the PWG >for the following reasons: > > - Receiving events from printers is a pervasive and profound problem > across the entire computer-based landscape. The SNMP Printer MIB > has actually done very little to improve this situation, not because > the MIB is faulty in some way, but because SNMP is faulty (or rather, > deficient) in providing event notification suitable for printers; > for example, the need to dynamically register for TRAPs, and to have > a reasonably reliable mechanism that can ensure you get those TRAPs. > > - My company (Underscore) develops (among other things) network printer > management software for client host systems (ie, not embedded in the > printer, per se). Many people have asked me why Underscore has not > yet developed and marketed a generic Printer MIB console. The reason > we have not is because such a product (or one based on the Printer MIB) > is easily usable by end-users and not just system administrators. > However, since this product would "come and go" (with respect to being > launched/terminated by the user), there is no way for the product to > receive TRAPs from the target printer(s)...which results in the need > for Underscore's product to poll like hell to maintain an accurate view > of the printer(s). As a result, Underscore (as well as others in the > PWG) believe that such a product could seriously impact performance on > the customer's network...and that the customer would find the product > next to useless (if not out-and-out dangerous). Not a pretty picture > for a product review, eh? > > So, Underscore has decided to address the (generic) need for an app > to dynamically register for the receipt of events from arbitrary > abstract entities (such as printers), in which the events may be of > many different types--including, but not limited to--SNMP TRAPs. > > As a result, Underscore believes that rapid and pervasive deployment > and acceptance of SENSE is best accomplished through close relationships > with printer vendors, particularly network printer vendors (and others > relating to network printing, such as network printer interface vendors). > >Of course, SENSE could be very, very applicable to MFPs, particularly >network-attached MFPs. I shall try to keep you informed of all SENSE >progress as best I can. For now, however, as long as you monitor the >PWG mailing list, then you'll get all the public information as it >arrives...at least until a separate SENSE mailing list is developed >(which will probably happen by June, I believe). > >Your comments about the "sanctioning" of the PWG (and related topics) >is quite timely, even for the SENSE project. Should the PWG dissolve >for whatever reason, then it might be useful to explore the MFPA as the >umbrella organization behind SENSE. > >By the way, while your published observations about the PWG's performance, >particularly with respect to the lack of written submissions, is quite >painful (personally, anyway), it's also very true. Kudos to you, Ray, >for being so up-front about this...while still maintaining a courteous >and professional tone in your writing. Perhaps Geoff Slater can take a >few tips from your recent postings. ;) > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Internet: jkm@underscore.com -- >-- Underscore, Inc. | Usenet: ..!uunet!mv.com!uscore!jkm -- >-- 41C Sagamore Park Road | Voice: (603) 889-7000 -- >-- Hudson, NH 03051-4915 | Fax: (603) 889-2699 -- >---------------------------------------------------------------------- > >----- Begin Included Message ----- > >>From cognisys.com!raylutz Tue Apr 23 02:08:53 1996 >Date: Mon, 22 Apr 96 23:07:48 -0700 (PDT) >X-Sender: raylutz@crash.cts.com >Mime-Version: 1.0 >To: jkm@underscore.com (JK Martin) >From: raylutz@cognisys.com (Raymond Lutz) >Subject: Re: The Printer Working Group as a "sanctioned" organization > >Jay: >Gee, thanks Jay... And, don't worry, I'm not thin skinned. > >I wanted to make a note to you that I am interested in the SENSE proposal. >Since this is a general purpose network facility (from the little I know of >it), I am wondering that the PWG is really not the best home for it. You may >find that there are other stomping grounds that are more willing to take on >such a project. From my observations, PWG is a one-project group, and until >they get formal procedures, they will not be able to handle much more. There >is too much blue sky and conversation and not enough written contributions. >Other groups won't allow anything to be submitted unless it is written, >meaning that the contributor has expended at least that amount of energy. >Should MFPA be interested in SENSE? >-Raymond > >At 10:39 PM 4/22/96 EDT, JK Martin wrote: >>Ray, >> >>Just so I'm not misinterpreted, I just wanted to drop you a personal >>note to say "Thanks!" for your continued observance and commentary >>to the PWG mailing list. >> >>I look forward to your future contributions. >> >> ...jay >> >> >> > >/*********************************************************************** >** Raymond Lutz Voice: 619-447-3246 >** Director R & D, Cognisys, Inc. Fax: 619-447-6872 >** MFPA EC Chair BBS: 619-447-2223 >** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com >** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA >** WWW: http://www.cognisys.com http://www.mfpa.org >***********************************************************************/ > >----- End Included Message ----- > > FYI -Raymond >Return-Path: >Date: Tue, 23 Apr 96 13:30 EDT >From: jkm@underscore.com (JK Martin) >To: raylutz@cognisys.com >Subject: MFPA interest in SENSE >Cc: jds@underscore.com, jkm@underscore.com >X-UIDL: 830323792.003 > >Ray, > >It's good to see that you're interested in SENSE. Let me see if I can >answer/address some of your questions/comments. > >Yes, SENSE is designed to be a general purpose network service. While >it is not explicitly and/or exclusively tied to printers, the design >goals of SENSE are such that printer-related event problems are used >as the primary target application problem domain; however, as you well >know, the kinds of events emanating from printers are relatively generic >across many other application problem domains, so SENSE should be quite >applicable for non-printer applications as well. > >Is the PWG the best home for SENSE? Maybe there are better "umbrellas" >to be found, but right now I personally choose to stay with the PWG >for the following reasons: > > - Receiving events from printers is a pervasive and profound problem > across the entire computer-based landscape. The SNMP Printer MIB > has actually done very little to improve this situation, not because > the MIB is faulty in some way, but because SNMP is faulty (or rather, > deficient) in providing event notification suitable for printers; > for example, the need to dynamically register for TRAPs, and to have > a reasonably reliable mechanism that can ensure you get those TRAPs. > > - My company (Underscore) develops (among other things) network printer > management software for client host systems (ie, not embedded in the > printer, per se). Many people have asked me why Underscore has not > yet developed and marketed a generic Printer MIB console. The reason > we have not is because such a product (or one based on the Printer MIB) > is easily usable by end-users and not just system administrators. > However, since this product would "come and go" (with respect to being > launched/terminated by the user), there is no way for the product to > receive TRAPs from the target printer(s)...which results in the need > for Underscore's product to poll like hell to maintain an accurate view > of the printer(s). As a result, Underscore (as well as others in the > PWG) believe that such a product could seriously impact performance on > the customer's network...and that the customer would find the product > next to useless (if not out-and-out dangerous). Not a pretty picture > for a product review, eh? > > So, Underscore has decided to address the (generic) need for an app > to dynamically register for the receipt of events from arbitrary > abstract entities (such as printers), in which the events may be of > many different types--including, but not limited to--SNMP TRAPs. > > As a result, Underscore believes that rapid and pervasive deployment > and acceptance of SENSE is best accomplished through close relationships > with printer vendors, particularly network printer vendors (and others > relating to network printing, such as network printer interface vendors). > >Of course, SENSE could be very, very applicable to MFPs, particularly >network-attached MFPs. I shall try to keep you informed of all SENSE >progress as best I can. For now, however, as long as you monitor the >PWG mailing list, then you'll get all the public information as it >arrives...at least until a separate SENSE mailing list is developed >(which will probably happen by June, I believe). > >Your comments about the "sanctioning" of the PWG (and related topics) >is quite timely, even for the SENSE project. Should the PWG dissolve >for whatever reason, then it might be useful to explore the MFPA as the >umbrella organization behind SENSE. > >By the way, while your published observations about the PWG's performance, >particularly with respect to the lack of written submissions, is quite >painful (personally, anyway), it's also very true. Kudos to you, Ray, >for being so up-front about this...while still maintaining a courteous >and professional tone in your writing. Perhaps Geoff Slater can take a >few tips from your recent postings. ;) > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Internet: jkm@underscore.com -- >-- Underscore, Inc. | Usenet: ..!uunet!mv.com!uscore!jkm -- >-- 41C Sagamore Park Road | Voice: (603) 889-7000 -- >-- Hudson, NH 03051-4915 | Fax: (603) 889-2699 -- >---------------------------------------------------------------------- > >----- Begin Included Message ----- > >>From cognisys.com!raylutz Tue Apr 23 02:08:53 1996 >Date: Mon, 22 Apr 96 23:07:48 -0700 (PDT) >X-Sender: raylutz@crash.cts.com >Mime-Version: 1.0 >To: jkm@underscore.com (JK Martin) >From: raylutz@cognisys.com (Raymond Lutz) >Subject: Re: The Printer Working Group as a "sanctioned" organization > >Jay: >Gee, thanks Jay... And, don't worry, I'm not thin skinned. > >I wanted to make a note to you that I am interested in the SENSE proposal. >Since this is a general purpose network facility (from the little I know of >it), I am wondering that the PWG is really not the best home for it. You may >find that there are other stomping grounds that are more willing to take on >such a project. From my observations, PWG is a one-project group, and until >they get formal procedures, they will not be able to handle much more. There >is too much blue sky and conversation and not enough written contributions. >Other groups won't allow anything to be submitted unless it is written, >meaning that the contributor has expended at least that amount of energy. >Should MFPA be interested in SENSE? >-Raymond > >At 10:39 PM 4/22/96 EDT, JK Martin wrote: >>Ray, >> >>Just so I'm not misinterpreted, I just wanted to drop you a personal >>note to say "Thanks!" for your continued observance and commentary >>to the PWG mailing list. >> >>I look forward to your future contributions. >> >> ...jay >> >> >> > >/*********************************************************************** >** Raymond Lutz Voice: 619-447-3246 >** Director R & D, Cognisys, Inc. Fax: 619-447-6872 >** MFPA EC Chair BBS: 619-447-2223 >** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com >** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA >** WWW: http://www.cognisys.com http://www.mfpa.org >***********************************************************************/ > >----- End Included Message ----- > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Ray, I do appreciate your interest in some sort of alignment of SENSE with the MFPA. There is much to gain by folding into SENSE the requirements of the MFPA, and I look forward to do so in the near future. However, in the future, PLEASE obtain permission from the author of the original email message before posting the author's private email to a public list. I would have gladly "cleaned up" my original private message to you if I had known you wished to make its contents public. ...jay ---------------------------------------------------------------------- -- JK Martin | Internet: jkm@underscore.com -- -- Underscore, Inc. | Usenet: ..!uunet!mv.com!uscore!jkm -- -- 41C Sagamore Park Road | Voice: (603) 889-7000 -- -- Hudson, NH 03051-4915 | Fax: (603) 889-2699 -- ---------------------------------------------------------------------- Ray, I do appreciate your interest in some sort of alignment of SENSE with the MFPA. There is much to gain by folding into SENSE the requirements of the MFPA, and I look forward to do so in the near future. However, in the future, PLEASE obtain permission from the author of the original email message before posting the author's private email to a public list. I would have gladly "cleaned up" my original private message to you if I had known you wished to make its contents public. ...jay ---------------------------------------------------------------------- -- JK Martin | Internet: jkm@underscore.com -- -- Underscore, Inc. | Usenet: ..!uunet!mv.com!uscore!jkm -- -- 41C Sagamore Park Road | Voice: (603) 889-7000 -- -- Hudson, NH 03051-4915 | Fax: (603) 889-2699 -- ---------------------------------------------------------------------- Oops! My apologies. I read it over and I couldn't see anything that was the least bit harmful, but I still accept your complaint as valid. I accept your remarks and admit that the posting was done without your permission, and therefore, it was not appropriate. It won't happen again. -Raymond At 05:32 PM 5/6/96 EDT, JK Martin wrote: >Ray, > >I do appreciate your interest in some sort of alignment of SENSE >with the MFPA. There is much to gain by folding into SENSE the >requirements of the MFPA, and I look forward to do so in the near >future. > >However, in the future, PLEASE obtain permission from the author >of the original email message before posting the author's private >email to a public list. > >I would have gladly "cleaned up" my original private message to you >if I had known you wished to make its contents public. > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Internet: jkm@underscore.com -- >-- Underscore, Inc. | Usenet: ..!uunet!mv.com!uscore!jkm -- >-- 41C Sagamore Park Road | Voice: (603) 889-7000 -- >-- Hudson, NH 03051-4915 | Fax: (603) 889-2699 -- >---------------------------------------------------------------------- > > Oops! My apologies. I read it over and I couldn't see anything that was the least bit harmful, but I still accept your complaint as valid. I accept your remarks and admit that the posting was done without your permission, and therefore, it was not appropriate. It won't happen again. -Raymond At 05:32 PM 5/6/96 EDT, JK Martin wrote: >Ray, > >I do appreciate your interest in some sort of alignment of SENSE >with the MFPA. There is much to gain by folding into SENSE the >requirements of the MFPA, and I look forward to do so in the near >future. > >However, in the future, PLEASE obtain permission from the author >of the original email message before posting the author's private >email to a public list. > >I would have gladly "cleaned up" my original private message to you >if I had known you wished to make its contents public. > > ...jay > >---------------------------------------------------------------------- >-- JK Martin | Internet: jkm@underscore.com -- >-- Underscore, Inc. | Usenet: ..!uunet!mv.com!uscore!jkm -- >-- 41C Sagamore Park Road | Voice: (603) 889-7000 -- >-- Hudson, NH 03051-4915 | Fax: (603) 889-2699 -- >---------------------------------------------------------------------- > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPI-1, Version 5.5 is available on the ftp site, as follows: ftp://ftp.cts.com/pub/MFPA/mfpi1_55.zip This file was compressed using PKZIP and password encrypted. If you don't have the password, please contact the MFPA office. There are two files provided: 650chg55.doc winword 6.0, changes from IS-650 is650_55.doc winword 6.0, current review version. If you enable revision marks, the marking shown reflects changes from the IS-650 interim standard version. Enjoy! -Raymond MFPI-1, Version 5.5 is available on the ftp site, as follows: ftp://ftp.cts.com/pub/MFPA/mfpi1_55.zip This file was compressed using PKZIP and password encrypted. If you don't have the password, please contact the MFPA office. There are two files provided: 650chg55.doc winword 6.0, changes from IS-650 is650_55.doc winword 6.0, current review version. If you enable revision marks, the marking shown reflects changes from the IS-650 interim standard version. Enjoy! -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPI-1, Version 5.5 is available on the ftp site, as follows: ftp://ftp.cts.com/pub/MFPA/mfpi1_55.zip This file was compressed using PKZIP and password encrypted. If you don't have the password, please contact the MFPA office. There are two files provided: 650chg55.doc winword 6.0, changes from IS-650 is650_55.doc winword 6.0, current review version. If you enable revision marks, the marking shown reflects changes from the IS-650 interim standard version. Enjoy! -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPA - Multifunction Peripheral Association Overview Presentation Meeting Notice, 5/23/1996, Tokyo, Japan ============================================================= Contacts: --------- MFPA: Raymond Lutz, (Chair MFPA) Cognisys, Inc. V:1-800-603-MFPA or 619-447-1127 F:619-447-6872 Email: MFPA-request@mfpa.org; raylutz@cognisys.com Please contact Kathleen Cuban at MFPA to confirm your attendance. Date: ----- MFPA Presentation Meeting: May 23rd (Thursday),1996,1:00pm - 4:30pm Place: ------ Le Pacific Meridien, 3, Takanawa, Minato-ku, Tokyo 108, Japan Room Location: 29th Floor, "Party Room" Reservations: 03-3445-6711, Fax: 03-3445-5137 Rates: $124.00 per night, Mention MFPA Background: ----------- The Multifunction Peripheral Association is focussed on technical and marketing issues to support the multifunction peripheral (i.e. Printer/Scanner/Fax/Copier/Telephonics) industry and market. This meeting will be organized as an overview presentation of MFPA activities. (This is not a General MFPA meeting and no decisions or voting will take place. This is not a technical Working Group meeting.) All interested parties are invited. Please RSVP if you plan to attend. Since there is limited space available, we must confirm your reservation. There is no charge for the meeting. Agenda: ------- Welcome and introductions Brief MFPA organization overview, member companies listed. MFPA technical initiatives: General Liaison with many standards groups and related trade associations. MFPI-1 (TIA IS-650 and PN-3756) Troika-1 API for MFP’s Transportable Document Format and Interdomain Job Submission Internet-interoperable facsimile MFPA Marketing Initiatives: Levels of Service and MFPA Compatibility Certification Integrated Office Conference, ‘96 (IOC96) The meeting report is available as: http://www.mfpa.org/mr960501.htm This is a web page that can be access through your favorite web browser. Please note that we managed to stomp on the ftp document log web page. So don't try to access the report in that manner. Note also that we did not test all of the links in the report yet. -Raymond MFPA - Multifunction Peripheral Association Overview Presentation Meeting Notice, 5/23/1996, Tokyo, Japan ============================================================= Contacts: --------- MFPA: Raymond Lutz, (Chair MFPA) Cognisys, Inc. V:1-800-603-MFPA or 619-447-1127 F:619-447-6872 Email: MFPA-request@mfpa.org; raylutz@cognisys.com Please contact Kathleen Cuban at MFPA to confirm your attendance. Date: ----- MFPA Presentation Meeting: May 23rd (Thursday),1996,1:00pm - 4:30pm Place: ------ Le Pacific Meridien, 3, Takanawa, Minato-ku, Tokyo 108, Japan Room Location: 29th Floor, "Party Room" Reservations: 03-3445-6711, Fax: 03-3445-5137 Rates: $124.00 per night, Mention MFPA Background: ----------- The Multifunction Peripheral Association is focussed on technical and marketing issues to support the multifunction peripheral (i.e. Printer/Scanner/Fax/Copier/Telephonics) industry and market. This meeting will be organized as an overview presentation of MFPA activities. (This is not a General MFPA meeting and no decisions or voting will take place. This is not a technical Working Group meeting.) All interested parties are invited. Please RSVP if you plan to attend. Since there is limited space available, we must confirm your reservation. There is no charge for the meeting. Agenda: ------- Welcome and introductions Brief MFPA organization overview, member companies listed. MFPA technical initiatives: General Liaison with many standards groups and related trade associations. MFPI-1 (TIA IS-650 and PN-3756) Troika-1 API for MFP's Transportable Document Format and Interdomain Job Submission Internet-interoperable facsimile MFPA Marketing Initiatives: Levels of Service and MFPA Compatibility Certification Integrated Office Conference, '96 (IOC96) /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ The meeting report is available as: http://www.mfpa.org/mr960501.htm This is a web page that can be access through your favorite web browser. Please note that we managed to stomp on the ftp document log web page. So don't try to access the report in that manner. Note also that we did not test all of the links in the report yet. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ MFPA - Multifunction Peripheral Association Overview Presentation Meeting Notice, 5/23/1996, Tokyo, Japan ============================================================= Contacts: --------- MFPA: Raymond Lutz, (Chair MFPA) Cognisys, Inc. V:1-800-603-MFPA or 619-447-1127 F:619-447-6872 Email: MFPA-request@mfpa.org; raylutz@cognisys.com Please contact Kathleen Cuban at MFPA to confirm your attendance. Date: ----- MFPA Presentation Meeting: May 23rd (Thursday),1996,1:00pm - 4:30pm Place: ------ Le Pacific Meridien, 3, Takanawa, Minato-ku, Tokyo 108, Japan Room Location: 29th Floor, "Party Room" Reservations: 03-3445-6711, Fax: 03-3445-5137 Rates: $124.00 per night, Mention MFPA Background: ----------- The Multifunction Peripheral Association is focussed on technical and marketing issues to support the multifunction peripheral (i.e. Printer/Scanner/Fax/Copier/Telephonics) industry and market. This meeting will be organized as an overview presentation of MFPA activities. (This is not a General MFPA meeting and no decisions or voting will take place. This is not a technical Working Group meeting.) All interested parties are invited. Please RSVP if you plan to attend. Since there is limited space available, we must confirm your reservation. There is no charge for the meeting. Agenda: ------- Welcome and introductions Brief MFPA organization overview, member companies listed. MFPA technical initiatives: General Liaison with many standards groups and related trade associations. MFPI-1 (TIA IS-650 and PN-3756) Troika-1 API for MFP’s Transportable Document Format and Interdomain Job Submission Internet-interoperable facsimile MFPA Marketing Initiatives: Levels of Service and MFPA Compatibility Certification Integrated Office Conference, ‘96 (IOC96) MFPA - Multifunction Peripheral Association Overview Presentation Meeting Notice, 5/23/1996, Tokyo, Japan ============================================================= Contacts: --------- MFPA: Raymond Lutz, (Chair MFPA) Cognisys, Inc. V:1-800-603-MFPA or 619-447-1127 F:619-447-6872 Email: MFPA-request@mfpa.org; raylutz@cognisys.com Please contact Kathleen Cuban at MFPA to confirm your attendance. Date: ----- MFPA Presentation Meeting: May 23rd (Thursday),1996,1:00pm - 4:30pm Place: ------ Le Pacific Meridien, 3, Takanawa, Minato-ku, Tokyo 108, Japan Room Location: 29th Floor, "Party Room" Reservations: 03-3445-6711, Fax: 03-3445-5137 Rates: $124.00 per night, Mention MFPA Background: ----------- The Multifunction Peripheral Association is focussed on technical and marketing issues to support the multifunction peripheral (i.e. Printer/Scanner/Fax/Copier/Telephonics) industry and market. This meeting will be organized as an overview presentation of MFPA activities. (This is not a General MFPA meeting and no decisions or voting will take place. This is not a technical Working Group meeting.) All interested parties are invited. Please RSVP if you plan to attend. Since there is limited space available, we must confirm your reservation. There is no charge for the meeting. Agenda: ------- Welcome and introductions Brief MFPA organization overview, member companies listed. MFPA technical initiatives: General Liaison with many standards groups and related trade associations. MFPI-1 (TIA IS-650 and PN-3756) Troika-1 API for MFP's Transportable Document Format and Interdomain Job Submission Internet-interoperable facsimile MFPA Marketing Initiatives: Levels of Service and MFPA Compatibility Certification Integrated Office Conference, '96 (IOC96) /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Dear PWG: I have completed a contribution outlining the changes to RFC-1759 and the IANA registry procedures to accommodate the requirements of MFPA. This proposal does not really change the MIB structure at all, but does clarify the formats accepted by given interpreters. I went out on a limb to define a bunch of MIME types that don't exist yet, but I think the means to define these is at hand and simple. I tried to upload these to the HP ftp server, but I couldn't remember the special tricks involved. So, instead, I loaded them to the MFPA ftp server. If you can tell me how to do it, I can load them, or you are welcome to make copies on the PWG server. MFPA wants to keep copies of these anyway. This submission to your group will be reviewed also by the TR29 committee next week. Sorry, I can't be at your meeting as I am scheduled to be in Tokyo. You can access these as: ftp://ftp.cts.com/pub/MFPA/pwglang.doc (winword 6.0) ftp://ftp.cts.com/pub/MFPA/pwglang.eps (Postscript) You should review this with revisions marking displayed and/or printed for best results. The PS version has revision marks printed. I haven't done it yet, but I was thinking of submitting this directly to the MIME list. Maybe after it is approved (yes!) then it would be the right time. I'm sure that the MIME enhancements authors may have some comment as well, and some of the types that I pulled from the MIME registry may in fact not match those in the MIB. Respectfully submitted, -Raymond Lutz /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Dear PWG: I have completed a contribution outlining the changes to RFC-1759 and the IANA registry procedures to accommodate the requirements of MFPA. This proposal does not really change the MIB structure at all, but does clarify the formats accepted by given interpreters. I went out on a limb to define a bunch of MIME types that don't exist yet, but I think the means to define these is at hand and simple. I tried to upload these to the HP ftp server, but I couldn't remember the special tricks involved. So, instead, I loaded them to the MFPA ftp server. If you can tell me how to do it, I can load them, or you are welcome to make copies on the PWG server. MFPA wants to keep copies of these anyway. This submission to your group will be reviewed also by the TR29 committee next week. Sorry, I can't be at your meeting as I am scheduled to be in Tokyo. You can access these as: ftp://ftp.cts.com/pub/MFPA/pwglang.doc (winword 6.0) ftp://ftp.cts.com/pub/MFPA/pwglang.eps (Postscript) You should review this with revisions marking displayed and/or printed for best results. The PS version has revision marks printed. I haven't done it yet, but I was thinking of submitting this directly to the MIME list. Maybe after it is approved (yes!) then it would be the right time. I'm sure that the MIME enhancements authors may have some comment as well, and some of the types that I pulled from the MIME registry may in fact not match those in the MIB. Respectfully submitted, -Raymond Lutz /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ [A fancy version of this document is available as: ftp://ftp.cts.com/pub/MFPA/dn96_046.doc ] MFPA May 10, 1996 DN:MFPA-96-046 To: IEEE-1284.4 Working Group, c/o Larry Stein, chair From: MFPA, c/o Raymond Lutz Re: Liaison regarding Disposition of IEEE-1284.4 and Service Discovery Dear IEEE-1284.4: The MFPA has reviewed the progress of the IEEE-1284.4 committee and is happy with the general direction of the work. However, there are some issues which should be aired that this liaison attempts to bring out. Please accept these concerns as input to your committee from a group of approximately 40 interested MFP companies and potential IEEE-1284.4 users who may not attend all IEEE-1284.4 working group meetings. Let me state the following points: 1) The IEEE-1284.4 committee is basing the work on a general scheme provided by HP, which includes flow-control methodology which uses material with intellectual property claims by HP. 2) IEEE-1284.4 committee has already voted on this issue and there is little question that the HP-MLC specification will be used as a basis for the IEEE-1284.4 standard. In addition, the committee has agreed to make any resulting standard "backward compatible" with HP's current implementation. 3) HP has stated a willingness to license the patented material in a "Fair and non-discriminatory manner", for no charge to anyone wishing to purchase the standard. However, HP is unwilling to grant licenses until the draft reaches some stable point, or a first draft is at least produced. So today, there are no licenses granted by HP. 4) The address and service discovery (session layer) functions have been proposed as additions to the original HP-MLC specification. 5) It is not necessary to have session layer functionality in the IEEE-1284.4 standard. This is clear since HP is using the version without these services included. 6) A proposal has been provided to the committee (by this contributor) wherein the session layer functionality is performed within the IEEE-1284 and proposed IEEE-1284.4 standards without any new extensions. This proposal is viewed not as an optimal solution, but as a reasonable and pragmatic solution to expedite the completion of the IEEE-1284.4 standard without the generation of session layer services. 7) Other standards exist that can provide the session layer. If such a layer is eventually defined by IEEE-1284.4 (or other group, say 1284.5) it would then be possible to use it in conjunction with the IEEE-1284.4 layer without a session layer. IS-650 is another alternative to provide such session layer functions. 8) The MFPA supports the idea of a separate session (address and service discovery) layer standard. This results in a layered architecture which is more in-line with the OSI network layers, and should expedite the generation of an IEEE-1284.4 draft, which should allow HP to begin licensing of the patented technology. Therefore, the session (address and service discovery) functions should be split from the IEEE-1284.4 transport layer. IEEE-1284.4 should instead define a method of determining: - If a session layer is in use. - Which session layer it is. The IEEE-1284.4 should delay no further in producing a draft of this specification which is sufficient for licensing purposes of the patented technology. Respectfully Submitted, - Raymond Lutz, MFPA MultiFunction Peripheral Association 1010 Old Chase Ave., Suite B, El Cajon, CA 92020-7739 Tel: 619/447-1127 Toll Free: 800/603-MFPA Fax: 619/447-6872 E-Mail: mfpa-request@mfpa.org /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Ray I'm happy with WORDCRFT. (We have been called everything from WOODCRAFT to WODCRIFT so I have no pride!) CFP as a "language" - fine. The current version is 4.1 but there will be a 4.2 this summer to handle the additions for the latest batch of CFP machines. >1) What is the language specifier. Should we use: > > "WORDCRFT|CFP|3.7" > >I would like to keep the vendor name down to 8 characters to be compatible >with the SCSI spec (Wordcraft is currently not in it). CFP is a good >language name. What about the version? I just made up 3.7. > >Please supply a document reference for the references section. > I have downloaded the latest IS650 but I have no password (sob, sob!) As soon as I can read it through and get the comments of my techies I will let you know any problem areas. I agree about the packet protocol and the teaks we made to IEEE 1284 to speed up turnarounds. By all means let's do it the "standard" way. >2) We need to comment on the stuff in CFP that won't work when used with >MFPI. I don't think there is too much of this, but there is some >comments on the fact that we won't be using the CFP packet structure or IEEE-1284 details from the CFP specification. There's a program on TV tonight called "The rise of the nerds" - all about Bill G and his original contest with IBM. I think I will give it a miss and disappear inside a nice bottle of Burgundy! Computers can be so BORING can't they! Cheers Mike ****************************************************************** * Mike Lake mlake@wcraft.win-uk.net * * Managing Director * * Wordcraft International Limited Voice: +44-1332-371428 * * Kelmscot House Fax: +44-1332-295525 * * Vernon Street BBS: +44-1332-380034 * * Derby DE1 1FR * * United Kingdom * * * * Comms software products: LaserFAX/HydraFAX/CFP/ReSponD/Sopwith * ****************************************************************** Ray I'm happy with WORDCRFT. (We have been called everything from WOODCRAFT to WODCRIFT so I have no pride!) CFP as a "language" - fine. The current version is 4.1 but there will be a 4.2 this summer to handle the additions for the latest batch of CFP machines. >1) What is the language specifier. Should we use: > > "WORDCRFT|CFP|3.7" > >I would like to keep the vendor name down to 8 characters to be compatible >with the SCSI spec (Wordcraft is currently not in it). CFP is a good >language name. What about the version? I just made up 3.7. > >Please supply a document reference for the references section. > I have downloaded the latest IS650 but I have no password (sob, sob!) As soon as I can read it through and get the comments of my techies I will let you know any problem areas. I agree about the packet protocol and the teaks we made to IEEE 1284 to speed up turnarounds. By all means let's do it the "standard" way. >2) We need to comment on the stuff in CFP that won't work when used with >MFPI. I don't think there is too much of this, but there is some >comments on the fact that we won't be using the CFP packet structure or IEEE-1284 details from the CFP specification. There's a program on TV tonight called "The rise of the nerds" - all about Bill G and his original contest with IBM. I think I will give it a miss and disappear inside a nice bottle of Burgundy! Computers can be so BORING can't they! Cheers Mike ****************************************************************** * Mike Lake mlake@wcraft.win-uk.net * * Managing Director * * Wordcraft International Limited Voice: +44-1332-371428 * * Kelmscot House Fax: +44-1332-295525 * * Vernon Street BBS: +44-1332-380034 * * Derby DE1 1FR * * United Kingdom * * * * Comms software products: LaserFAX/HydraFAX/CFP/ReSponD/Sopwith * ****************************************************************** Hi: I just returned from the TR29 meeting near Newark, NJ. I left slightly early so that I can prepare for my trip to Tokyo next week. I presented the MIME media-types as a possible standard way to handle the Contents-Type field of T.434 (BFT). As a result, I had a side conversation with Steven Pershau of National Communication Systems (some sort of government agency that is interesting in insuring that the critical U.S. communications always stays up). He says that ITU-T does not recognize IETF as any more than a "small-m" member, the same status that any company can have, such as HP, AT&T, Rockwell, etc. (Although this was offered to the IETF free of charge, others must pay a large fee). He says that ITU-T sends virtually all of their recommendations to the IETF, but never has the IETF contributed anything to the ITU. The problem he says with IETF getting more stature at least in these circles, is that IETF has no "leader" who is responsible for the results of the IETF. In the ITU, this person is Mr. Ermer. Other organizations always have a contact person who is ultimately responsible for the quality and coordination of organization activities. IETF has no such person. It sounds like IETF does want higher stature with these institutions, but since they are based on international treaties, they must have some strict agreements with "Large-M" members, such as ISO, ECMA, etc. to be in compliance with these treaties. Therefore, the small-m status. I really admire the good work and obvious results of the IETF. Maybe their approach is better for the fluid nature of the Internet and the future of communication standards. However, some serious organizational changes will have to happen in either IETF or ITU before IETF will be seen as a "legitimate" standards body. I just hope this doesn't get in the way of harmonizing ITU and IETF standards (proposals from myself and others have been seen which suggest that a new generation of facsimile should be based on internet standards -- not the other way around!) -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi: I just returned from the TR29 meeting near Newark, NJ. I left slightly early so that I can prepare for my trip to Tokyo next week. I presented the MIME media-types as a possible standard way to handle the Contents-Type field of T.434 (BFT). As a result, I had a side conversation with Steven Pershau of National Communication Systems (some sort of government agency that is interesting in insuring that the critical U.S. communications always stays up). He says that ITU-T does not recognize IETF as any more than a "small-m" member, the same status that any company can have, such as HP, AT&T, Rockwell, etc. (Although this was offered to the IETF free of charge, others must pay a large fee). He says that ITU-T sends virtually all of their recommendations to the IETF, but never has the IETF contributed anything to the ITU. The problem he says with IETF getting more stature at least in these circles, is that IETF has no "leader" who is responsible for the results of the IETF. In the ITU, this person is Mr. Ermer. Other organizations always have a contact person who is ultimately responsible for the quality and coordination of organization activities. IETF has no such person. It sounds like IETF does want higher stature with these institutions, but since they are based on international treaties, they must have some strict agreements with "Large-M" members, such as ISO, ECMA, etc. to be in compliance with these treaties. Therefore, the small-m status. I really admire the good work and obvious results of the IETF. Maybe their approach is better for the fluid nature of the Internet and the future of communication standards. However, some serious organizational changes will have to happen in either IETF or ITU before IETF will be seen as a "legitimate" standards body. I just hope this doesn't get in the way of harmonizing ITU and IETF standards (proposals from myself and others have been seen which suggest that a new generation of facsimile should be based on internet standards -- not the other way around!) -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Overview Presentation Meeting Notice Multifunction Peripheral Association UPDATE! ======= The Meeting Room Location of the MFPA Overview Presentation Meeting has been changed to the "KIKYO" Banquet Room located on the first/lobby floor. The complete information is listed below: Date: MFPA Presentation Meeting: May 23rd (Thursday), 1996, 1:00 pm - 4:30 pm Place: Le Pacific Meridien, 3, Takanawa, Minato-ku, Tokyo 108, Japan Room Location: 1st Floor, "KIKYO Banquet Room" =============================================== Reservations: 03-3445-6711, Fax: 03-3445-5137 Rates: $124.00 per night, Mention MFPA Background: =========== The Multifunction Peripheral Association is focussed on technical and marketing issues to support the multifunction peripheral (i.e. Printer/Scanner/Fax/Copier/Telephonics) industry and market. This meeting will be organized as an overview presentation of MFPA activities. (This is not a General MFPA meeting and no decisions or voting will take place. This is not a technical Working Group meeting.) All interested parties are invited. Please RSVP if you plan to attend. Since there is limited space available, we must confirm your reservation. There is no charge for the meeting. Agenda: ------- Welcome and introductions Brief MFPA organization overview, member companies listed. MFPA technical initiatives: General Liaison with many standards groups and related trade associations. MFPI-1 (TIA IS-650 and PN-3756) Troika-1 API for MFP’s Transportable Document Format and Interdomain Job Submission Internet-interoperable facsimile MFPA Marketing Initiatives: Levels of Service and MFPA Compatibility Certification Integrated Office Conference, ‘96 (IOC96)  Overview Presentation Meeting Notice Multifunction Peripheral Association UPDATE! ======= The Meeting Room Location of the MFPA Overview Presentation Meeting has been changed to the "KIKYO" Banquet Room located on the first/lobby floor. The complete information is listed below: Date: MFPA Presentation Meeting: May 23rd (Thursday), 1996, 1:00 pm - 4:30 pm Place: Le Pacific Meridien, 3, Takanawa, Minato-ku, Tokyo 108, Japan Room Location: 1st Floor, "KIKYO Banquet Room" =============================================== Reservations: 03-3445-6711, Fax: 03-3445-5137 Rates: $124.00 per night, Mention MFPA Background: =========== The Multifunction Peripheral Association is focussed on technical and marketing issues to support the multifunction peripheral (i.e. Printer/Scanner/Fax/Copier/Telephonics) industry and market. This meeting will be organized as an overview presentation of MFPA activities. (This is not a General MFPA meeting and no decisions or voting will take place. This is not a technical Working Group meeting.) All interested parties are invited. Please RSVP if you plan to attend. Since there is limited space available, we must confirm your reservation. There is no charge for the meeting. Agenda: ------- Welcome and introductions Brief MFPA organization overview, member companies listed. MFPA technical initiatives: General Liaison with many standards groups and related trade associations. MFPI-1 (TIA IS-650 and PN-3756) Troika-1 API for MFP's Transportable Document Format and Interdomain Job Submission Internet-interoperable facsimile MFPA Marketing Initiatives: Levels of Service and MFPA Compatibility Certification Integrated Office Conference, '96 (IOC96)  /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ I can't get to the ftp sites listed on the MFPA web page. when I run straight ftp, there is no MFPA directory under pub. Did it move ? Thanks Try: cd /pub/MFPA instead of looking for it, once you are logged into ftp.cts.com. It is a long story, but that is how it is set up now. Let me know if this solves your problem. -Raymond At 10:43 AM 5/22/96 -0700, Bill Ataras wrote: >I can't get to the ftp sites listed on the MFPA web page. when I run straight ftp, there is no MFPA directory under pub. Did it move ? > >Thanks > > > Try: cd /pub/MFPA instead of looking for it, once you are logged into ftp.cts.com. It is a long story, but that is how it is set up now. Let me know if this solves your problem. -Raymond At 10:43 AM 5/22/96 -0700, Bill Ataras wrote: >I can't get to the ftp sites listed on the MFPA web page. when I run straight ftp, there is no MFPA directory under pub. Did it move ? > >Thanks > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Comments?? ------------ DALLAS(Reuter) - Texas Instruments, Inc. (TXN-NYSE) said Tuesday that it has developed new technology that will allow it to build computer chips more powerful than 20 of todays state-of-the-art personal computers. The semiconductor maker said its new "Timeline" technology will allow the company to put a variety of computer functions, including memory, microprocessor and other special functions on a single chip, reducing the number of chips required for consumer electronic devices by up to 90 percent. It said the new technology allows it to build transistors as small as 0.18 microns, allowing it to put up to 125 million transistors on a single chip. A micron is a millionth of a meter. Texas Instruments said computer chips based on the technology would lead to a new generation of products such as picturephones, computers that recognize human speech patterns, or automated teller machines that recognize a bank customers face or fingerprint. It said such chips will also increase the battery life of mobile electronic devices such as cellular phones or laptop computers because the new chips require less power than current technology. The company said it expected to begin shipping the new chips in 1997. The stock Texas Instruments jumped $3 to $54.75 in late trading on the New York Stock Exchange. The company said its new chip will initially be intended for wireless communications, Internet servers -- computers used to manage traffic over the Internet -- and high-end computer workstations. A Texas Instruments spokeswoman said a single Timeline chip would have the processing power of more than 20 PC's. In addition to the the tasks handled by the microprocessor that is the heart of the personal computer, the chip can handle tasks performed by other chips in the machine. Thus, a Timeline-based chip would have the power of more than 50 single Intel Corp. Pentium microprocessors, or 30 Sun Microsystems, Inc. UltraSpark microprocessors, the chips used to run high-powered Sun computer workstations. The company said such chips could also replace 100 built-in computer modems. An Internet server, which handles incoming calls from hundreds of users at a single time, must have modems to support all those callers. The chip would also allow communications at far faster data transmission rates than currently possible using the 28.8-kilobit technology curently available. The chip maker said the new technology relies on Texas Instrument's capacity to produce semiconductor chips in ever smaller microscopic sizes. In addition, the chip takes advantage of the company's leadership in the area of Digital Signal Processors (DSP), chips that reduce sound waves and other data from the real world into a single form that can be processed and analyzed more easily by a computer. Texas Instruments is the dominant maker of DSP chips with about 44 percent of the world market. Tom Geldner - Geldner Associates Marketing, advertising & PR Tel: 619/578-0096 -- Fax: 619/578-0828 www: http://ourworld.compuserve.com/homepages/geldner New transistor technology is a long way from being realized into the sort of products listed. apparently it is just a further miniturization. -Raymond > >Comments?? > >------------ >DALLAS(Reuter) - Texas Instruments, Inc. (TXN-NYSE) said Tuesday that it >has >developed new technology that will allow it to build computer chips more >powerful >than 20 of todays state-of-the-art personal computers. > >The semiconductor maker said its new "Timeline" technology will allow >the company to >put a variety of computer functions, including memory, microprocessor >and other >special functions on a single chip, reducing the number of chips >required for >consumer electronic devices by up to 90 percent. > >It said the new technology allows it to build transistors as small as >0.18 microns, >allowing it to put up to 125 million transistors on a single chip. A >micron is a >millionth of a meter. > >Texas Instruments said computer chips based on the technology would lead >to a new >generation of products such as picturephones, computers that recognize >human speech >patterns, or automated teller machines that recognize a bank customers >face or >fingerprint. > >It said such chips will also increase the battery life of mobile >electronic devices >such as cellular phones or laptop computers because the new chips >require less power >than current technology. > >The company said it expected to begin shipping the new chips in 1997. > >The stock Texas Instruments jumped $3 to $54.75 in late trading on the >New York Stock >Exchange. > >The company said its new chip will initially be intended for wireless >communications, >Internet servers -- computers used to manage traffic over the Internet >-- and >high-end computer workstations. > >A Texas Instruments spokeswoman said a single Timeline chip would have >the processing >power of more than 20 PC's. > >In addition to the the tasks handled by the microprocessor that is the >heart of the >personal computer, the chip can handle tasks performed by other chips in >the machine. > >Thus, a Timeline-based chip would have the power of more than 50 single >Intel Corp. >Pentium microprocessors, or 30 Sun Microsystems, Inc. UltraSpark >microprocessors, the >chips used to run high-powered Sun computer workstations. > >The company said such chips could also replace 100 built-in computer >modems. An >Internet server, which handles incoming calls from hundreds of users at >a single >time, must have modems to support all those callers. > >The chip would also allow communications at far faster data transmission >rates than >currently possible using the 28.8-kilobit technology curently available. > > >The chip maker said the new technology relies on Texas Instrument's >capacity to >produce semiconductor chips in ever smaller microscopic sizes. > >In addition, the chip takes advantage of the company's leadership in the >area of >Digital Signal Processors (DSP), chips that reduce sound waves and other >data from >the real world into a single form that can be processed and analyzed >more easily by a >computer. > >Texas Instruments is the dominant maker of DSP chips with about 44 >percent of the >world market. > > > > > >Tom Geldner - Geldner Associates >Marketing, advertising & PR >Tel: 619/578-0096 -- Fax: 619/578-0828 >www: http://ourworld.compuserve.com/homepages/geldner > > > New transistor technology is a long way from being realized into the sort of products listed. apparently it is just a further miniturization. -Raymond > >Comments?? > >------------ >DALLAS(Reuter) - Texas Instruments, Inc. (TXN-NYSE) said Tuesday that it >has >developed new technology that will allow it to build computer chips more >powerful >than 20 of todays state-of-the-art personal computers. > >The semiconductor maker said its new "Timeline" technology will allow >the company to >put a variety of computer functions, including memory, microprocessor >and other >special functions on a single chip, reducing the number of chips >required for >consumer electronic devices by up to 90 percent. > >It said the new technology allows it to build transistors as small as >0.18 microns, >allowing it to put up to 125 million transistors on a single chip. A >micron is a >millionth of a meter. > >Texas Instruments said computer chips based on the technology would lead >to a new >generation of products such as picturephones, computers that recognize >human speech >patterns, or automated teller machines that recognize a bank customers >face or >fingerprint. > >It said such chips will also increase the battery life of mobile >electronic devices >such as cellular phones or laptop computers because the new chips >require less power >than current technology. > >The company said it expected to begin shipping the new chips in 1997. > >The stock Texas Instruments jumped $3 to $54.75 in late trading on the >New York Stock >Exchange. > >The company said its new chip will initially be intended for wireless >communications, >Internet servers -- computers used to manage traffic over the Internet >-- and >high-end computer workstations. > >A Texas Instruments spokeswoman said a single Timeline chip would have >the processing >power of more than 20 PC's. > >In addition to the the tasks handled by the microprocessor that is the >heart of the >personal computer, the chip can handle tasks performed by other chips in >the machine. > >Thus, a Timeline-based chip would have the power of more than 50 single >Intel Corp. >Pentium microprocessors, or 30 Sun Microsystems, Inc. UltraSpark >microprocessors, the >chips used to run high-powered Sun computer workstations. > >The company said such chips could also replace 100 built-in computer >modems. An >Internet server, which handles incoming calls from hundreds of users at >a single >time, must have modems to support all those callers. > >The chip would also allow communications at far faster data transmission >rates than >currently possible using the 28.8-kilobit technology curently available. > > >The chip maker said the new technology relies on Texas Instrument's >capacity to >produce semiconductor chips in ever smaller microscopic sizes. > >In addition, the chip takes advantage of the company's leadership in the >area of >Digital Signal Processors (DSP), chips that reduce sound waves and other >data from >the real world into a single form that can be processed and analyzed >more easily by a >computer. > >Texas Instruments is the dominant maker of DSP chips with about 44 >percent of the >world market. > > > > > >Tom Geldner - Geldner Associates >Marketing, advertising & PR >Tel: 619/578-0096 -- Fax: 619/578-0828 >www: http://ourworld.compuserve.com/homepages/geldner > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Bravo! Looks like I'll have that Cray in my wristwatch real soon now. Apparently TI has figured out how to lay down .18 micron silicon versus the typical .30-.50 today. 125 million transistors is a bunch. I think a Pentium is about 4 million. I'm sure this is expensive at the moment but within a couple of years we should see ASICs with lots more capability. Bob. /********************************************************************* ** Bob McComiskie Voice: 617-229-7021 ** ** Senior Product Manager Fax: 617-229-7120 ** ** Xionics Document Technologies, Inc. rmccomiskie@xionics.com ** ** 70 Blanchard Road ** ** Burlington, MA 01803 USA http://www.xionics.com ** *********************************************************************/ ______________________________ Reply Separator _________________________________ Subject: News from TI. Author: Tom Geldner <75300.1541@CompuServe.COM> at INTERNET Date: 5/30/96 4:20 PM Comments?? ------------ DALLAS(Reuter) - Texas Instruments, Inc. (TXN-NYSE) said Tuesday that it has developed new technology that will allow it to build computer chips more powerful than 20 of todays state-of-the-art personal computers. The semiconductor maker said its new "Timeline" technology will allow the company to put a variety of computer functions, including memory, microprocessor and other special functions on a single chip, reducing the number of chips required for consumer electronic devices by up to 90 percent. It said the new technology allows it to build transistors as small as 0.18 microns, allowing it to put up to 125 million transistors on a single chip. A micron is a millionth of a meter. Texas Instruments said computer chips based on the technology would lead to a new generation of products such as picturephones, computers that recognize human speech patterns, or automated teller machines that recognize a bank customers face or fingerprint. It said such chips will also increase the battery life of mobile electronic devices such as cellular phones or laptop computers because the new chips require less power than current technology. The company said it expected to begin shipping the new chips in 1997. The stock Texas Instruments jumped $3 to $54.75 in late trading on the New York Stock Exchange. The company said its new chip will initially be intended for wireless communications, Internet servers -- computers used to manage traffic over the Internet -- and high-end computer workstations. A Texas Instruments spokeswoman said a single Timeline chip would have the processing power of more than 20 PC's. In addition to the the tasks handled by the microprocessor that is the heart of the personal computer, the chip can handle tasks performed by other chips in the machine. Thus, a Timeline-based chip would have the power of more than 50 single Intel Corp. Pentium microprocessors, or 30 Sun Microsystems, Inc. UltraSpark microprocessors, the chips used to run high-powered Sun computer workstations. The company said such chips could also replace 100 built-in computer modems. An Internet server, which handles incoming calls from hundreds of users at a single time, must have modems to support all those callers. The chip would also allow communications at far faster data transmission rates than currently possible using the 28.8-kilobit technology curently available. The chip maker said the new technology relies on Texas Instrument's capacity to produce semiconductor chips in ever smaller microscopic sizes. In addition, the chip takes advantage of the company's leadership in the area of Digital Signal Processors (DSP), chips that reduce sound waves and other data from the real world into a single form that can be processed and analyzed more easily by a computer. Texas Instruments is the dominant maker of DSP chips with about 44 percent of the world market. Tom Geldner - Geldner Associates Marketing, advertising & PR Tel: 619/578-0096 -- Fax: 619/578-0828 www: http://ourworld.compuserve.com/homepages/geldner Hi Larry: When this reflector was set up, the question of whether it was to be moderated or not was broached. The consensus at that meeting was that it was not moderated. So, I'm not the moderator, I'm just expressing my own opinion. I don't think that the TI announcement was anything worth posting, but it was and so I responded to it since I was addressed also. Maybe this was a mistake of the sender. For myself, I wouldn't mind seeing APPROPRIATE press releases from MEMBER COMPANIES on the reflector. "APPROPRIATE" would mean that it has some direct bearing on the MFP industry (not indirect, such as a new transistor size capability). In this case, the TI release fit into neither constraint. But that is only my opinion. At this time, the reflector is "unmoderated". Until a consensus blows the other way, I guess "common sense" is the best guide -- you will only be moderated by the flaming you will get if you step on someone's toes! - Raymond P.S. Please post your press release. At 07:08 AM 5/31/96 -0700, Larry Simpson wrote: >Ray, et al, > >Regarding the TI press release on their new DSP architecture..... > >It appears to me that the Reflector is not the place to be posting >press releases and either member or non-member "propaganda". > >If I'm in fact wrong, and it is now encouraged, please advise. We >(Motorola) put out a press release on Power PC core+Communications I/O >processor+SIMD architecture on one chip, and would be happy to put >the press release on the reflector, if this is now the norm. > >I believe there needs to be clarification on the policy. > >Regards, >Larry Simpson >Market Development & Sales Manager - Imaging Peripherals Mkt. >Motorola Semiconductor Products Sector > > I have attached a text version of the report of the MFPA meeting in Shinigawa, Tokyo, Japan. Also, you may browse this at: http://www.mfpa.org/mr960523.htm The presentations are linked into the www version so you can review them. Sorry this took so long. -Raymond -------------------------------------------------------- MR960523.w DN: MFPA-96-050 Multifunction Peripheral Association Tokyo Presentation Meeting Report Location: Le Pacific Meridien Hotel, Shinigawa, Tokyo, Japan Date: May 23, 1996 Prepared by: Raymond Lutz, EC Chair, MFPA Administration: -------------- Attendees signed in and introduced themselves. The attendees were as follows: Takashi Inoue -- Canon, Inc., Product Development Head Quarters Noriyoshi Kurotsu -- Canon, Inc., Product Development Head Quarters Naoyuki Matsumoto -- Canon, Inc., Product Development Head Quarters Mamoru Osada -- Canon, Inc., Product Development Head Quarters Yasuhiko Sasaki -- Canon, Inc., Office Systems Research & Development Kan Torii -- Canon, Inc., Product Development Head Quarters Teruo Yamamoto -- Canon, Inc., Systems Technology Devel. Planning Mitsumasa Nezu -- Fujitsu Limited, Compact Printer Division Koichi Takahashi -- JBMA-Japan Business Machine Makers Association Masao Yamaguchi -- Matsushita Electric Co., Ltd., Product Planning Division Yoshinori Aoki -- Matsushita Graphic Communication Systems, Inc., Engineering Research Tatsuo Imai -- Matsushita Graphic Communication Systems, Inc., Corp. Engineering Teruo Aoki -- Mita Industrial Co., Ltd. Koichi Shibata -- Mita Industrial Co., Ltd. Michio Shiraogawa -- Murata Machinery, Ltd., Communication Equipment Toshiaki Fukai -- NEC, Personal Communication Sadamoto Kato -- NEC, Market Development Hajime Koto -- NEC, Engineering Planning and Corordination Tomohiro Shinada -- NEC, Personal Communication Makoto Kawakami -- Oak Technology/ Pixel Magic Akio Matsubara -- Ricoh, Research Development Group Yasuyuki Shirai -- Ricoh, System Solution Business Division Masaharu Hirao -- Sanyo, Information Product Business Head Quarters Michiko Kurata -- Wind River Systems Japan Report: ------- After welcome and introductions, Raymond Lutz made three presentations which are available for your review. The first presentation, "The Integrated Office and MFPs: Introduction to MFPA and the future vision of the MFP in the Integrated Office Environment" -- tokyo6bc.ppt, covers the MFPA organization and provides a overview of the MFPI and Troika API. This is an updated presentation similar to that presented at IOC'95. The second presentation, "Job Submission and the Transportable Document Format" -- tokyo6cc.ppt, is also a presentation that follows closely that presented at IOC'95. Finally, the last presentation, "Troika MFP API" -- troikac.ppt, provides a basis for the new work on both the Troika-1 and Troika-2 API levels. I especially invite you to look over this presentation since it is new, and provides a conceptual basis for the Troika-1 and -2 API's. Unfortunately, these presentations are not complete without my explanations of the slides, but they are still useful to give some conceptual basis for the new API work. Also, there were some announcements regarding IOC'96 and new logos of the MFPA. During the presentation, the attendees were very attentive and seemed to generally understand the material. There is obviously a major language barrier that exists. At the end of the meeting, there were no questions posed as a group. In side discussions, however, there were a number of interesting ideas that surfaced. First, I was surprised by an idea to create MFPA-J, the Japanese "Chapter" of the MFPA, which could provide a structured way to pass information between the US chapter and the Japan chapter. There was general support among individuals that I talked with regarding continued involvement, although no commitment was made in the general session. I sort of like the idea of the Japan chapter myself. Another idea was that the JBMA and other industry groups in Japan may be willing to subsidize some of the translation that would be required. MFPA may wish to subsidize some of this as well. The JBMA representative (Takahashi-san) suggested that JBMA wants to be "in cooperation with" MFPA for IOC'96. I will be working with them to make this happen as well. The people I talked with thought that the session was a good match with what they needed, and was a good start to get things rolling. Let's consider the idea of MFPA-J and establishment of a solid communication channel between the MFPA-US and MFPA-J. This is perhaps the best idea to come out of these sessions. Respectfully submitted, Raymond Lutz Exective Council Chair Please send comments or suggestions to MFPA-request@mfpa.org. To MFPA Members and Prospective Members: Please join me in welcoming "Olivetti Lexkion" to the MFPA, as of May, 1996. Their primary contact will be Evasio Bocca. Here is a brief description of Olivetti Lexikon: Olivetti Lexikon Spa (100% owned by Olivetti Spa), formed on 1 January 1996, operates on the office products, printers and office supplies market, where it combines leading-edge technology such as bubble ink-jet printing with the historical know-how (in design, industrial processes, distribution) that has been a hallmark of Olivetti products for almost one hundred years. Its offer comprises printers, fax equipment, typewriters, copiers, cash registers, calculators, and office supplies. A growing proportion of the company's revenues arises from products using the bubble ink-jet printing technology; in fact, Olivetti Lexikon is the leading European manufacturer of bubble ink-jet printers and fax equipment. Contact Information: Evasio Bocca Olivetti Lexikon Via Torino 603 Ivrea, TO 10090, Italy Voice: 39-125-52-4248 Fax: 39-125-52-4240 Web: www.olivetti.it/lex/welcome.htm -Kathleen R. Cuban Director of Member Services ************************************************************************** Kathleen R. Cuban Phone: 800-603-MFPA or Director of Member Services 619-447-1127 MFPA Fax: 619-447-6872 1010 Old Chase Ave., Ste B EMail: MFPA-request@mfpa.org El Cajon, CA 92020 ************************************************************************** I have attached a text version of the report of the MFPA meeting in Shinigawa, Tokyo, Japan. Also, you may browse this at: http://www.mfpa.org/mr960523.htm The presentations are linked into the www version so you can review them. Sorry this took so long. -Raymond -------------------------------------------------------- MR960523.w DN: MFPA-96-050 Multifunction Peripheral Association Tokyo Presentation Meeting Report Location: Le Pacific Meridien Hotel, Shinigawa, Tokyo, Japan Date: May 23, 1996 Prepared by: Raymond Lutz, EC Chair, MFPA Administration: -------------- Attendees signed in and introduced themselves. The attendees were as follows: Takashi Inoue -- Canon, Inc., Product Development Head Quarters Noriyoshi Kurotsu -- Canon, Inc., Product Development Head Quarters Naoyuki Matsumoto -- Canon, Inc., Product Development Head Quarters Mamoru Osada -- Canon, Inc., Product Development Head Quarters Yasuhiko Sasaki -- Canon, Inc., Office Systems Research & Development Kan Torii -- Canon, Inc., Product Development Head Quarters Teruo Yamamoto -- Canon, Inc., Systems Technology Devel. Planning Mitsumasa Nezu -- Fujitsu Limited, Compact Printer Division Koichi Takahashi -- JBMA-Japan Business Machine Makers Association Masao Yamaguchi -- Matsushita Electric Co., Ltd., Product Planning Division Yoshinori Aoki -- Matsushita Graphic Communication Systems, Inc., Engineering Research Tatsuo Imai -- Matsushita Graphic Communication Systems, Inc., Corp. Engineering Teruo Aoki -- Mita Industrial Co., Ltd. Koichi Shibata -- Mita Industrial Co., Ltd. Michio Shiraogawa -- Murata Machinery, Ltd., Communication Equipment Toshiaki Fukai -- NEC, Personal Communication Sadamoto Kato -- NEC, Market Development Hajime Koto -- NEC, Engineering Planning and Corordination Tomohiro Shinada -- NEC, Personal Communication Makoto Kawakami -- Oak Technology/ Pixel Magic Akio Matsubara -- Ricoh, Research Development Group Yasuyuki Shirai -- Ricoh, System Solution Business Division Masaharu Hirao -- Sanyo, Information Product Business Head Quarters Michiko Kurata -- Wind River Systems Japan Report: ------- After welcome and introductions, Raymond Lutz made three presentations which are available for your review. The first presentation, "The Integrated Office and MFPs: Introduction to MFPA and the future vision of the MFP in the Integrated Office Environment" -- tokyo6bc.ppt, covers the MFPA organization and provides a overview of the MFPI and Troika API. This is an updated presentation similar to that presented at IOC'95. The second presentation, "Job Submission and the Transportable Document Format" -- tokyo6cc.ppt, is also a presentation that follows closely that presented at IOC'95. Finally, the last presentation, "Troika MFP API" -- troikac.ppt, provides a basis for the new work on both the Troika-1 and Troika-2 API levels. I especially invite you to look over this presentation since it is new, and provides a conceptual basis for the Troika-1 and -2 API's. Unfortunately, these presentations are not complete without my explanations of the slides, but they are still useful to give some conceptual basis for the new API work. Also, there were some announcements regarding IOC'96 and new logos of the MFPA. During the presentation, the attendees were very attentive and seemed to generally understand the material. There is obviously a major language barrier that exists. At the end of the meeting, there were no questions posed as a group. In side discussions, however, there were a number of interesting ideas that surfaced. First, I was surprised by an idea to create MFPA-J, the Japanese "Chapter" of the MFPA, which could provide a structured way to pass information between the US chapter and the Japan chapter. There was general support among individuals that I talked with regarding continued involvement, although no commitment was made in the general session. I sort of like the idea of the Japan chapter myself. Another idea was that the JBMA and other industry groups in Japan may be willing to subsidize some of the translation that would be required. MFPA may wish to subsidize some of this as well. The JBMA representative (Takahashi-san) suggested that JBMA wants to be "in cooperation with" MFPA for IOC'96. I will be working with them to make this happen as well. The people I talked with thought that the session was a good match with what they needed, and was a good start to get things rolling. Let's consider the idea of MFPA-J and establishment of a solid communication channel between the MFPA-US and MFPA-J. This is perhaps the best idea to come out of these sessions. Respectfully submitted, Raymond Lutz Exective Council Chair Please send comments or suggestions to MFPA-request@mfpa.org. /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Hi Larry: When this reflector was set up, the question of whether it was to be moderated or not was broached. The consensus at that meeting was that it was not moderated. So, I'm not the moderator, I'm just expressing my own opinion. I don't think that the TI announcement was anything worth posting, but it was and so I responded to it since I was addressed also. Maybe this was a mistake of the sender. For myself, I wouldn't mind seeing APPROPRIATE press releases from MEMBER COMPANIES on the reflector. "APPROPRIATE" would mean that it has some direct bearing on the MFP industry (not indirect, such as a new transistor size capability). In this case, the TI release fit into neither constraint. But that is only my opinion. At this time, the reflector is "unmoderated". Until a consensus blows the other way, I guess "common sense" is the best guide -- you will only be moderated by the flaming you will get if you step on someone's toes! - Raymond P.S. Please post your press release. At 07:08 AM 5/31/96 -0700, Larry Simpson wrote: >Ray, et al, > >Regarding the TI press release on their new DSP architecture..... > >It appears to me that the Reflector is not the place to be posting >press releases and either member or non-member "propaganda". > >If I'm in fact wrong, and it is now encouraged, please advise. We >(Motorola) put out a press release on Power PC core+Communications I/O >processor+SIMD architecture on one chip, and would be happy to put >the press release on the reflector, if this is now the norm. > >I believe there needs to be clarification on the policy. > >Regards, >Larry Simpson >Market Development & Sales Manager - Imaging Peripherals Mkt. >Motorola Semiconductor Products Sector > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ << I don't think that the TI announcement was anything worth posting, but it was and so I responded to it since I was addressed also. Maybe this was a mistake of the sender. >> Hmmm. Obviously my apology to you and Larry for doing this didn't make it to the real world. For what it's worth, the item was not a press release; it was an article brief posted on Ziff-Davis' ZDNET. I did not realize it was inappropriate content for the MFPA and I will refrain from making posts of this nature in the future. Tom Geldner - Geldner Associates Marketing, advertising & PR Tel: 619/578-0096 -- Fax: 619/578-0828 www: http://ourworld.compuserve.com/homepages/geldner << I don't think that the TI announcement was anything worth posting, but it was and so I responded to it since I was addressed also. Maybe this was a mistake of the sender. >> Hmmm. Obviously my apology to you and Larry for doing this didn't make it to the real world. For what it's worth, the item was not a press release; it was an article brief posted on Ziff-Davis' ZDNET. I did not realize it was inappropriate content for the MFPA and I will refrain from making posts of this nature in the future. Tom Geldner - Geldner Associates Marketing, advertising & PR Tel: 619/578-0096 -- Fax: 619/578-0828 www: http://ourworld.compuserve.com/homepages/geldner To MFPA Members and Prospective Members: Please join me in welcoming JetFax, Inc. to the MFPA, as of April, 1996. Their primary contact will be Rudy Prince. Here is a brief description of JetFax, Inc.: JetFax develops, manufactures, and markets multifunction products, controllers and host software. Its products include both inkjet and laser machines, sold under both JetFax and OEM brand names. In addition, JetFax both supplies and licenses its multifunction controller technology for use in both retail and mid-range products. Its latest multifunction offering, JetSuite, is a comprehensive, integrated host-based software package which supports all of the capabilities of multifunction machines through a single user interface. JetSuite includes a powerful document manager, full text search and retrieval, scanning and OCR, Class 1 & 2 faxing, digital copying with enhanced imaging support, and an integrated printer driver. JetSuite will support the MFPI standard interface over a 1284 parallel port and is expected to begin shipping in the fall of 1996. Both Light and Pro versions are available for OEM bundles and options. We support the following: Manufacturer of end-product Turnkey controller supplier MFP controller technology Host MFP applications MFP embedded software/firmware Contact Information: JetFax, Inc. Rudy Prince 1376 Willow Road Menlo Park, California 94025 415/324-0600 fax: 415/326-6003 e-mail: rudy@jetfax.com www: http:\\www.jetfax.com - Kathleen R. Cuban Director of Member Services To MFPA Members and Prospective Members: Please join me in welcoming JetFax, Inc. to the MFPA, as of April, 1996. Their primary contact will be Rudy Prince. Here is a brief description of JetFax, Inc.: JetFax develops, manufactures, and markets multifunction products, controllers and host software. Its products include both inkjet and laser machines, sold under both JetFax and OEM brand names. In addition, JetFax both supplies and licenses its multifunction controller technology for use in both retail and mid-range products. Its latest multifunction offering, JetSuite, is a comprehensive, integrated host-based software package which supports all of the capabilities of multifunction machines through a single user interface. JetSuite includes a powerful document manager, full text search and retrieval, scanning and OCR, Class 1 & 2 faxing, digital copying with enhanced imaging support, and an integrated printer driver. JetSuite will support the MFPI standard interface over a 1284 parallel port and is expected to begin shipping in the fall of 1996. Both Light and Pro versions are available for OEM bundles and options. We support the following: Manufacturer of end-product Turnkey controller supplier MFP controller technology Host MFP applications MFP embedded software/firmware Contact Information: JetFax, Inc. Rudy Prince 1376 Willow Road Menlo Park, California 94025 415/324-0600 fax: 415/326-6003 e-mail: rudy@jetfax.com www: http:\\www.jetfax.com - Kathleen R. Cuban Director of Member Services ************************************************************************** Kathleen R. Cuban Phone: 800-603-MFPA or Director of Member Services 619-447-1127 MFPA Fax: 619-447-6872 1010 Old Chase Ave., Ste B EMail: MFPA-request@mfpa.org El Cajon, CA 92020 ************************************************************************** I am a Macintosh user and have been unable to locate a mac-compatible multi-function peripheral. Do you know if anyone manufactures one? If so, I would appreciate the help. Thank you. We just completed adding new "groovy" graphics features to the MFPA web site. Please check it out at: http://www.mfpa.org Enjoy! -Raymond The following technical description relates to the current draft of MFPI-1 (revised IS-650). There is a statement regarding the possibility of continuing to observe events from an events-mode reserved subsystem that has been interrupted. The current version states that when an events-mode reserved subsystem is interrupted, no further event information will be transferred to the host until the events mode reservation is re-established. The following is the current text from that section: SAC Requests Session Reservation, Subsystem Events Reserved =========================================================== If the Host already has the subsystem reserved in Events Mode, and the SAC wishes to reserve the subsystem, then the Session Mode request will interrupt the Events Mode session. When this interruption occurs, the "STS ;" statement is provided to the Host, and the SAC will have complete control of the subsystem. No further event information is passed to the Host until after the interruption is removed. Then the "STS " message is sent to the Host to indicate that Events Mode has been reestablished on the channel, and event information will again be sent to the Host. It is recommended that the Host re-initialize the subsystem to insure that the expected state exists in that subsystem and the event information will be returned in the desired SSCL and in the desired format. The Host can then downgrade the reservation to Events Mode to wait for events from the subsystem that are of interest. *** The following is the proposed text *** SAC Requests Session Reservation, Subsystem Events Reserved =========================================================== If the Host already has the subsystem reserved in Events Mode, and the SAC wishes to reserve the subsystem, then the Session Mode request will interrupt the Events Mode session. When this interruption occurs, the "STS ;" statement is provided to the Host, and the SAC will have complete control of the subsystem. Further event information may be transferred to the host during the interrupted interval. The "STS " message is sent to the Host to indicate that Events Mode has been reestablished on the channel, and event information will again be sent to the Host. It is recommended that the Host re-initialize the subsystem to insure that the expected state exists in that subsystem and the event information will be returned in the desired SSCL and in the desired format. The Host can then downgrade the reservation to Events Mode to wait for events from the subsystem that are of interest. *** End of Proposed change *** You will note that the only change is that event information MAY be transferred to the host in the interrupted state. Consider the following scenario (This is proposed to be included in the standard as informative material). We will assume that the host is connected to the MFP and wishes to continue to get events from a subsystem that is to be used in a walk-up mode of operation. For this example, we will assume that the subsystem is the printer, and the walk-up user will be making copies with the subsystem. 1. Host reserves the subsystem in events mode. ("RSRV 20 3;") This is the "quiesent" if the host wishes to completely monitor the state of the MFP, so that a paper-tray removal will be noticed by the host, for example. 2. Initialize the printer to produce events in the desired format. 3. Host observes events on User subchannel in the current SSCL format or on the Supervisor subchannel as "STS xx;" MFPL statements. (In the current version of MFPI-1, it was agreed that the defined STS codes would not attempt to "correct" the operation of SSCLs that were deficient in some manner. Most historical printer languages, for example, produce very little in the way of status from the printer.) 4. Walk-up user requests copy (for example). 5. Stand-Alone Controller (SAC) reserves printer subsystem, MFP emits "STS 21;" ("STS ;") to host on Supervisor channel of the printer to indicate that the events mode reservation is being interrupted. (This used to mean that event reports would no longer be sent to the host.) 6. During copier operation, events may continue to be sent to the host, depending on the implementation of the subsystem and it's initialized state. Although events are being sent to the host, they are for "information only" and the host may not "upgrade" the reservation to session mode until the SAC has completed operation. It will do no good for the MFP to send "HINQ?" to the host during this interval since the host cannot reserve the subsystem. 7. At the completion of copier operation, "STS 22;" ("STS ;") is sent to host on the supervisor channel of the printer. 8. Host reinitializes the printer subsystem to provide events in the desired format, the same as step 2. 9. Repeat Step 3, observe events. 10. Host wishes to print, sends "RSRV 20, 2;" to enter session mode. When "STS 0" is returned from the MFP, the host may then initialize the printer and begin the print job. 11. Walk-up user requests COPY job (during printing). MFP sends "STS 23;" ("STS ;") to the host on the Supervisor channel of the printer subsystem to indicate that a walk-up user wishes to utilize the printer. 12. Host may (a) suspend the print job and allow the COPY job to continue, or (b) finish the print job and require the walk-up user to wait until it is completed. 13. In case 12(a) or (b), suspension or completion of the print job is a function of the SSCL for the printer. After the job is suspended or completed, the host may then either (a) Free the subsystem ("RSRV 20 0;") and let the SAC run the copy job (with no events feedback) or (b) degrade to "events" mode ("RSRV 20 3;"). Continue from step 5. ====== END OF EXAMPLE ====== -Raymond Regarding MFPI-1 reservation transitions: It appears that in the current version of MFPI-1, the "Table 3: Reservation Actions Matrix" and "Figure 4: Reservation Actions State Diagram" can be improved somewhat to provide more information. The Matrix assumes that the current reservation mode and the reason for change always involves different hosts. The following common situation is not adequately addressed: Current subsystem reserve mode = Events Reason for change: Host requests session reservation The current revision of the standard states that this transition is invalid, since it is assuming that such a transition would be prompted by a second host entity. It is true, however, that the same host may want to make such a change, for example, in the case where a subsystem is reserved in events mode and the host wishes to use that subsystem, and therefore upgrade it to session reservation mode. Therefore, the box in the matrix would be filled in, and an arc would exist in the state diagram for this transition. Another simplification was that the arcs to FREE were not included in the state diagram, and there is no column in the table for the Host FREEing the system ("RSRV xx 0;"). Proposed action: 1) Modify the table and state transition diagram with the assumption that only a single host is modifying the reservation level (i.e. fill in most of the boxes which now show "invalid"). Add corresponding sections to the text. 2) Add a column to the table for the host requesting the FREE reservation mode. 3) Modify the state transition diagram to reflect the improvement in the table. Implications: These changes are strictly editorial in nature and should improve the readers ability to interpret the intention of this important section. -Raymond We just completed adding new "groovy" graphics features to the MFPA web site. Please check it out at: http://www.mfpa.org Enjoy! -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ The following technical description relates to the current draft of MFPI-1 (revised IS-650). There is a statement regarding the possibility of continuing to observe events from an events-mode reserved subsystem that has been interrupted. The current version states that when an events-mode reserved subsystem is interrupted, no further event information will be transferred to the host until the events mode reservation is re-established. The following is the current text from that section: SAC Requests Session Reservation, Subsystem Events Reserved =========================================================== If the Host already has the subsystem reserved in Events Mode, and the SAC wishes to reserve the subsystem, then the Session Mode request will interrupt the Events Mode session. When this interruption occurs, the "STS ;" statement is provided to the Host, and the SAC will have complete control of the subsystem. No further event information is passed to the Host until after the interruption is removed. Then the "STS " message is sent to the Host to indicate that Events Mode has been reestablished on the channel, and event information will again be sent to the Host. It is recommended that the Host re-initialize the subsystem to insure that the expected state exists in that subsystem and the event information will be returned in the desired SSCL and in the desired format. The Host can then downgrade the reservation to Events Mode to wait for events from the subsystem that are of interest. *** The following is the proposed text *** SAC Requests Session Reservation, Subsystem Events Reserved =========================================================== If the Host already has the subsystem reserved in Events Mode, and the SAC wishes to reserve the subsystem, then the Session Mode request will interrupt the Events Mode session. When this interruption occurs, the "STS ;" statement is provided to the Host, and the SAC will have complete control of the subsystem. Further event information may be transferred to the host during the interrupted interval. The "STS " message is sent to the Host to indicate that Events Mode has been reestablished on the channel, and event information will again be sent to the Host. It is recommended that the Host re-initialize the subsystem to insure that the expected state exists in that subsystem and the event information will be returned in the desired SSCL and in the desired format. The Host can then downgrade the reservation to Events Mode to wait for events from the subsystem that are of interest. *** End of Proposed change *** You will note that the only change is that event information MAY be transferred to the host in the interrupted state. Consider the following scenario (This is proposed to be included in the standard as informative material). We will assume that the host is connected to the MFP and wishes to continue to get events from a subsystem that is to be used in a walk-up mode of operation. For this example, we will assume that the subsystem is the printer, and the walk-up user will be making copies with the subsystem. 1. Host reserves the subsystem in events mode. ("RSRV 20 3;") This is the "quiesent" if the host wishes to completely monitor the state of the MFP, so that a paper-tray removal will be noticed by the host, for example. 2. Initialize the printer to produce events in the desired format. 3. Host observes events on User subchannel in the current SSCL format or on the Supervisor subchannel as "STS xx;" MFPL statements. (In the current version of MFPI-1, it was agreed that the defined STS codes would not attempt to "correct" the operation of SSCLs that were deficient in some manner. Most historical printer languages, for example, produce very little in the way of status from the printer.) 4. Walk-up user requests copy (for example). 5. Stand-Alone Controller (SAC) reserves printer subsystem, MFP emits "STS 21;" ("STS ;") to host on Supervisor channel of the printer to indicate that the events mode reservation is being interrupted. (This used to mean that event reports would no longer be sent to the host.) 6. During copier operation, events may continue to be sent to the host, depending on the implementation of the subsystem and it's initialized state. Although events are being sent to the host, they are for "information only" and the host may not "upgrade" the reservation to session mode until the SAC has completed operation. It will do no good for the MFP to send "HINQ?" to the host during this interval since the host cannot reserve the subsystem. 7. At the completion of copier operation, "STS 22;" ("STS ;") is sent to host on the supervisor channel of the printer. 8. Host reinitializes the printer subsystem to provide events in the desired format, the same as step 2. 9. Repeat Step 3, observe events. 10. Host wishes to print, sends "RSRV 20, 2;" to enter session mode. When "STS 0" is returned from the MFP, the host may then initialize the printer and begin the print job. 11. Walk-up user requests COPY job (during printing). MFP sends "STS 23;" ("STS ;") to the host on the Supervisor channel of the printer subsystem to indicate that a walk-up user wishes to utilize the printer. 12. Host may (a) suspend the print job and allow the COPY job to continue, or (b) finish the print job and require the walk-up user to wait until it is completed. 13. In case 12(a) or (b), suspension or completion of the print job is a function of the SSCL for the printer. After the job is suspended or completed, the host may then either (a) Free the subsystem ("RSRV 20 0;") and let the SAC run the copy job (with no events feedback) or (b) degrade to "events" mode ("RSRV 20 3;"). Continue from step 5. ====== END OF EXAMPLE ====== -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ Regarding MFPI-1 reservation transitions: It appears that in the current version of MFPI-1, the "Table 3: Reservation Actions Matrix" and "Figure 4: Reservation Actions State Diagram" can be improved somewhat to provide more information. The Matrix assumes that the current reservation mode and the reason for change always involves different hosts. The following common situation is not adequately addressed: Current subsystem reserve mode = Events Reason for change: Host requests session reservation The current revision of the standard states that this transition is invalid, since it is assuming that such a transition would be prompted by a second host entity. It is true, however, that the same host may want to make such a change, for example, in the case where a subsystem is reserved in events mode and the host wishes to use that subsystem, and therefore upgrade it to session reservation mode. Therefore, the box in the matrix would be filled in, and an arc would exist in the state diagram for this transition. Another simplification was that the arcs to FREE were not included in the state diagram, and there is no column in the table for the Host FREEing the system ("RSRV xx 0;"). Proposed action: 1) Modify the table and state transition diagram with the assumption that only a single host is modifying the reservation level (i.e. fill in most of the boxes which now show "invalid"). Add corresponding sections to the text. 2) Add a column to the table for the host requesting the FREE reservation mode. 3) Modify the state transition diagram to reflect the improvement in the table. Implications: These changes are strictly editorial in nature and should improve the readers ability to interpret the intention of this important section. -Raymond /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/ To MFPA Members and Prospective Members: Please join me in welcoming Symantec Corp. Delrina Group to the MFPA, as of May, 1996. Their primary contact will be Dave Wilmering. Here is a brief description of Symantec Corp. Delrina Group: Symantec Corporation develops, markets and supports a complete line of application and system software products designed to enhance individual and workgroup productivity as well as manage networked computing environments. Platforms supported include IBM personal computers and compatibles, Apple Macintosh computers a well as major network operating systems. Founded in 1982, the company's global operations span North America, Europe and several fast growing markets throughout Asia Pacific and Latin America. Information on the company and its products can be obtained by call (800)441-7234 toll free or (541)334-6054. Contact Information: Dave Wilmering Symantec Corp. Delrina Group 895 Don Mills Rd 500-2 Park Centre Toronto, ON M3C 1W3 Canada (416)446-8041 -Kathleen R. Cuban Director of Member Services ************************************************************************** Kathleen R. Cuban Phone: 800-603-MFPA or Director of Member Services 619-447-1127 MFPA Fax: 619-447-6872 1010 Old Chase Ave., Ste B EMail: MFPA-request@mfpa.org El Cajon, CA 92020 ************************************************************************** >Return-Path: >From: JFLANAGAN >To: raylutz >Subject: RE: Scanner MIB >Date: Wed, 26 Jun 96 15:56:00 EDT >Encoding: 163 TEXT >X-UIDL: 835826004.001 > > >Dear Raymond, > >Thank-you for your email and your interest in AIIM. First of all, let me >assure you that your memory is still intact, it was indeed Jean Baronas that >you met a number of years ago. However, she no longer works at AIIM. > >AIIM would be very interested in MIB for scanners standards project. To >give you some background to the AIIM standards process, let me explain the >steps of our project development. > >1) A project proposal is submitted to the AIIM Standards Board for review >and approval. > >2) Once the project proposal has been approved, it is either assigned to an >existing standards committee or a new committee is formed to handle the >project. > >3) Once the project is developed it must passed through the following >approval ballots > >a) committee ballot >b) stds brd ballot >c) AIIM National Standards Committee, AIIM Membership and ANSI public >Review > (these ballots occur simultaneously) >d) final ANSI Board of Standards Review (BSR) Approval. > > Before the project can be addressed at an AIIM Standards Week, it must be >approved by the AIIM Standards Board. The next AIIM standards Board meeting >is scheduled for July 30, 1996. This issue can be addressed at that meeting >if we can prepare the project proposal in time. I will attach the project >proposal form to this message. > >Please let me know if you need assistance in preparing the proposal or it >there are any other questions you may have. > >AIIM is very interested in the project and I appreciate you contacting me. > >Sincerely, > >Joanne Flanagan >Manager, ANSI/ISO Standards Program >AIIM International > > --------------------------- >AIIM 94-003 > >AIIM Standards Program > >Project Proposal Drafting Guidelines >For Standards and Technical Reports (TRs) > >April 11, 1994 > > >These guidelines are for use by individuals when drafting project proposals >for ANSI/AIIM standards and TRs. They are designed to minimize duplication >and maximize compatibility with other standards and TRs, and to enhance >their value through use in commercial technology. > >Following are seven (7) components of a complete project proposal. AIIM's >staff will work with you in gathering the necessary information to generate >a successful project proposal. > >1. Unambiguous technical description of the project > > - Clear definition of scope and intent > - Statements of what is not to be addressed, where appropriate > >NOTE: Graphical representations of the relationships of the proposed >project with an information system or other standards is recommended where >applicable. > >2. Need statement > > - Description of value to be realized > - Identification of target audience > - How target audience should benefit > >3. Commercial (potential) impact > > - Will commercial products need to be modified or developed in order >for the standard (or TR) to provide proposed benefits? > - Are current product providers identified and available to >participate in developing the standard or TR? > - Are there defacto standards available for the same purpose? If >so, identify. > >4. Coordination > > - Is there similar work elsewhere? NOTE: AIIM will assist in >researching this and identify necessary liaisons. > >5. Resources > > - Are volunteers identified and enlisted? > >6. Timing > > - Are there special considerations concerning the timeliness of the >work? > >7. Proposer identification > > - Name > - Address > - Telephone, FAX, E-Mail > > > > >Send the completed from to: Joanne Flanagan, Manager, Standards Program, >AIIM International, 1100 Wayne Avenue, Suite 1100, Silver Spring, MD 20910, >Phone: 301-587-8202, >FAX: 301-587-2711, e-mail: jflanagan@aiim.org > > > >K:\national\newproj.doc > > > ---------- >From: raylutz >To: jflanagan >Subject: Scanner MIB >Date: Monday, June 24, 1996 11:47AM > >Dear Joanne: > >I represent the MultiFunction Peripheral Association (MFPA). I may have met >you a number of years ago, however, my memory says it was Jean Baronas. >Anyway, I have several questions: > >1) To resolve this confusion about people: did Jean Baronas work with AIIM >at some time, perhaps your predecessor? > >2) At recent MFPA meetings, we discussed the need for a scanner MIB >(Management Information Base) akin to the recently completed Printer MIB. >These are used for network scanner management. In those meetings, we thought >that AIIM may want to be involved or perhaps sanction work in this regard, >since your organization is heavily oriented toward scanners in the >application of document capture for archival. > >2a) Do you think AIIM has an interest in this standards effort? >2b) Is there a way to broach this topic at the upcoming AIIM standards week? > >3) MFPA has a annual conference on October 21-23, 1996 in San Diego. It >might be a good idea if AIIM would have a presentation or a small table to >acquaint the attendees with your work. > >Sincerely, > -Raymond Lutz > >/*********************************************************************** >** Raymond Lutz Voice: 619-447-3246 >** Director R & D, Cognisys, Inc. Fax: 619-447-6872 >** MFPA EC Chair BBS: 619-447-2223 >** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com >** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA >** WWW: http://www.cognisys.com http://www.mfpa.org >***********************************************************************/ > > > >Return-Path: >From: JFLANAGAN >To: raylutz >Subject: RE: Scanner MIB >Date: Wed, 26 Jun 96 15:56:00 EDT >Encoding: 163 TEXT >X-UIDL: 835826004.001 > > >Dear Raymond, > >Thank-you for your email and your interest in AIIM. First of all, let me >assure you that your memory is still intact, it was indeed Jean Baronas that >you met a number of years ago. However, she no longer works at AIIM. > >AIIM would be very interested in MIB for scanners standards project. To >give you some background to the AIIM standards process, let me explain the >steps of our project development. > >1) A project proposal is submitted to the AIIM Standards Board for review >and approval. > >2) Once the project proposal has been approved, it is either assigned to an >existing standards committee or a new committee is formed to handle the >project. > >3) Once the project is developed it must passed through the following >approval ballots > >a) committee ballot >b) stds brd ballot >c) AIIM National Standards Committee, AIIM Membership and ANSI public >Review > (these ballots occur simultaneously) >d) final ANSI Board of Standards Review (BSR) Approval. > > Before the project can be addressed at an AIIM Standards Week, it must be >approved by the AIIM Standards Board. The next AIIM standards Board meeting >is scheduled for July 30, 1996. This issue can be addressed at that meeting >if we can prepare the project proposal in time. I will attach the project >proposal form to this message. > >Please let me know if you need assistance in preparing the proposal or it >there are any other questions you may have. > >AIIM is very interested in the project and I appreciate you contacting me. > >Sincerely, > >Joanne Flanagan >Manager, ANSI/ISO Standards Program >AIIM International > > --------------------------- >AIIM 94-003 > >AIIM Standards Program > >Project Proposal Drafting Guidelines >For Standards and Technical Reports (TRs) > >April 11, 1994 > > >These guidelines are for use by individuals when drafting project proposals >for ANSI/AIIM standards and TRs. They are designed to minimize duplication >and maximize compatibility with other standards and TRs, and to enhance >their value through use in commercial technology. > >Following are seven (7) components of a complete project proposal. AIIM's >staff will work with you in gathering the necessary information to generate >a successful project proposal. > >1. Unambiguous technical description of the project > > - Clear definition of scope and intent > - Statements of what is not to be addressed, where appropriate > >NOTE: Graphical representations of the relationships of the proposed >project with an information system or other standards is recommended where >applicable. > >2. Need statement > > - Description of value to be realized > - Identification of target audience > - How target audience should benefit > >3. Commercial (potential) impact > > - Will commercial products need to be modified or developed in order >for the standard (or TR) to provide proposed benefits? > - Are current product providers identified and available to >participate in developing the standard or TR? > - Are there defacto standards available for the same purpose? If >so, identify. > >4. Coordination > > - Is there similar work elsewhere? NOTE: AIIM will assist in >researching this and identify necessary liaisons. > >5. Resources > > - Are volunteers identified and enlisted? > >6. Timing > > - Are there special considerations concerning the timeliness of the >work? > >7. Proposer identification > > - Name > - Address > - Telephone, FAX, E-Mail > > > > >Send the completed from to: Joanne Flanagan, Manager, Standards Program, >AIIM International, 1100 Wayne Avenue, Suite 1100, Silver Spring, MD 20910, >Phone: 301-587-8202, >FAX: 301-587-2711, e-mail: jflanagan@aiim.org > > > >K:\national\newproj.doc > > > ---------- >From: raylutz >To: jflanagan >Subject: Scanner MIB >Date: Monday, June 24, 1996 11:47AM > >Dear Joanne: > >I represent the MultiFunction Peripheral Association (MFPA). I may have met >you a number of years ago, however, my memory says it was Jean Baronas. >Anyway, I have several questions: > >1) To resolve this confusion about people: did Jean Baronas work with AIIM >at some time, perhaps your predecessor? > >2) At recent MFPA meetings, we discussed the need for a scanner MIB >(Management Information Base) akin to the recently completed Printer MIB. >These are used for network scanner management. In those meetings, we thought >that AIIM may want to be involved or perhaps sanction work in this regard, >since your organization is heavily oriented toward scanners in the >application of document capture for archival. > >2a) Do you think AIIM has an interest in this standards effort? >2b) Is there a way to broach this topic at the upcoming AIIM standards week? > >3) MFPA has a annual conference on October 21-23, 1996 in San Diego. It >might be a good idea if AIIM would have a presentation or a small table to >acquaint the attendees with your work. > >Sincerely, > -Raymond Lutz > >/*********************************************************************** >** Raymond Lutz Voice: 619-447-3246 >** Director R & D, Cognisys, Inc. Fax: 619-447-6872 >** MFPA EC Chair BBS: 619-447-2223 >** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com >** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA >** WWW: http://www.cognisys.com http://www.mfpa.org >***********************************************************************/ > > > /*********************************************************************** ** Raymond Lutz Voice: 619-447-3246 ** Director R & D, Cognisys, Inc. Fax: 619-447-6872 ** MFPA EC Chair BBS: 619-447-2223 ** 1010 Old Chase Ave., Suite B EMail: raylutz@cognisys.com ** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA ** WWW: http://www.cognisys.com http://www.mfpa.org ***********************************************************************/