>Return-Path: <pmp-owner at pwg.org>
>From: Bob Pentecost <bpenteco at boi.hp.com>
>To: "'Tom Hastings'" <hastings at cp10.es.xerox.com>
>Cc: "'PWG-pmp'" <pmp at pwg.org>
>Subject: RE: PMP> How should a PDF document be indicated in thePrinterMIB,
JobMonitoring MIB and IPP?
>Date: Mon, 17 Mar 1997 14:11:29 PST
>Encoding: 243 TEXT
>Sender: pmp-owner at pwg.org>>Tom,
>>Here are some answers to your questions...
>>> ----------
>From: Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
>> Sent: Monday, March 17, 1997 10:39 AM
>> To: Bob Pentecost
>> Subject: RE: PMP> How should a PDF document be indicated in
>thePrinterMIB, JobMonitoring MIB and IPP?
>>>> Bob,
>>>> I'm not familiar with MIME types that have been registered.
>> 1. Is PCL a registered type?
>>Yes. HP recently registered PCL, PCLXL and HP-GL.
>>> 2. Or do you have some printer-independent form of PCL registered?
>>We chose to register PCL as a single type. A viewer that recognizes the PCL
>MIME type must be able to understand all PCL commands if it is going to be
>able to display PCL files created for all printers.
>>> 3. Where is the MIME registry?
>>See http://www.isi.edu/in-notes/iana/assignments/media-types/application/>where you can find vnd.hp-HPGL, vnd.hp-PCL and vnd.hp-PCLXL.
>>> 4. When you use such a MIME type, are the document contents no longer
>> printer-specific? I.e., such a PCL MIME type would
>> be printable on both the LaserJet 5 and 5Si?
>>A file with MIME type PCL could be any level of PCL and could be intended
>for any printer from DeskJet to LaserJet to Color LaserJet.
>>Would it be printable on any printer? I think that depends on the software
>being used. If the software just dumps the file to a printer, it may not
>work. However, if the software converts the file to some intermediate
>format and then prints through a printer driver, it could be printed on any
>printer (the same as the way I can print a .pdf file by using my browser to
>view it and print it, even though my printer doesn't understand .pdf
>format).
>>>>> This is the kind of *significant* discussion I'd like to have in the PWG
>> with regard to PostScript and PCL. Can I make our mail discussion
>> public to the PWG, PMP, and JMP DLs? It looks like a great start to the
>> discussion.
>>Go ahead and make it public. In fact, I'll just cc PMP on this message.
>>>>> We need to understand the difference between a document format and
>> an interpreter (which is what I think is the distinction you are
>raising).
>> We need to understand which we are specifying in a job submision protocol
>> and so are reporting in the Job Monitoring MIB.
>>>> Thanks,
>> Tom
>>Bob Pentecost
>HP
>>>>>> At 15:03 03/14/97 PST, you wrote:
>> >Tom,
>> >
>> >For a document repository, wouldn't it make sense to use MIME types to
>know
>> >the document format?
>> >
>> >For PCL, we tend to make slight changes from printer to printer even
>though
>> >they are all considered to be PCL5e. There's no guarantee that a file
>> >generated for a LaserJet 5 will print correctly on a 5Si. Therefore, I
>> >would be hesitant to tie a language pairing to a document.
>> >
>> >Bob
>> >
>> >
>> >----------
>> >From: Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
>> >Sent: Thursday, March 13, 1997 5:06 PM
>> >To: Bob Pentecost
>> >Subject: RE: PMP> How should a PDF document be indicated in the
>> >PrinterMIB, JobMonitoring MIB and IPP?
>> >
>> >I think the PWG is aware of the appropriate language pairings for
>> >current levels, e.g., PCL4, PCL5, PCL5e, PS1, PS2, PS3.
>> >
>> >But is PDF part of PS3 or a separate document format or both?
>> >
>> >We really need help in deciding how to represent PCL and PS in these
>> >three standards: Printer MIB, Job Monitoring MIB, and IPP.
>> >Also these registrations will be used in other places, such as document
>> >repositories where a user wants to know the document-format, so he can
>> >decide which piece of software to use to acces it and to which printers
>> >he/she can send the document, but maybe such use of enums in document
>> >repositories is clouding the issue with the use of these enums in these
>> >three
>> >standards.
>> >
>> >PCL and PostScript "belong" to HP and Adobe, though the rest of us are
>> >affected too.
>> >
>> >Tom
>> >
>> >At 13:48 03/13/97 PST, you wrote:
>> >>Tom,
>> >
>> >I'm not sure what you're asking for. You say "We need some help here
>from
>> >>Adobe and HP on what is the best course to follow for the Printer MIB,
>Job
>> >>Monitoring MIB, and IPP." Is help needed to know which are the
>appropriate
>> >>language-version pairings? Or is help needed to understand whether or
>not
>> >>this feature is needed at all?
>> >>
>> >>Bob
>> >>
>> >>
>> >>
>> >>----------
>> >>From: Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
>> >>Sent: Thursday, March 13, 1997 1:31 PM
>> >>To: pmp at pwg.org; ipp at pwg.org; jmp at pwg.org>> >>Subject: PMP> How should a PDF document be indicated in the Printer
>MIB,
>> >>JobMonitoring MIB and IPP?
>> >>
>> >>Currently there is no enum registered for a PDF document-format for use
>> >>in the Printer MIB, the Job Monitoring MIB, and IPP.
>> >>
>> >>How should a PDF document be indicated in the Printer MIB, Job
>Monitoring
>> >>MIB and IPP?
>> >>
>> >>IPP is part of PostScript level 3, I understand, so that the PostScript
>> >>enum langPD(6) with a level of "3" in prtInterpreterLangLevel in the
>> >>Printer MIB could indicate a Printer that is capabile of consuming a
>PDF
>> >>file. But what about the Job Monitoring MIB where we don't have level
>> >>and IPP where we don't have level?
>> >>
>> >>Also it seems that a Printer might be able to consume PDF, but not any
>> >>PostScript level 3. Finally, in a document repository, it would be
>useful
>> >>to know that a document is a PDF file, so that a PDF reader can be used
>> >>to image it.
>> >>
>> >>We've discussed at several Printer Working Group meetings the idea of
>> >>registering combinations of language family and level in order to give
>> >them
>> >>distinct enums. So we could register PS1, PS2, PS3, and PDF. Also
>PCL5e,
>> >>PCL5, and PCL4 as separate enums for use when a particular level is
>> >>important.
>> >>And we could keep the current langPCL(3) and langPS(6) for use when
>level
>> >>is not important, or when the level is specified by other attributes,
>> >>such as in the Printer MIB.
>> >>
>> >>The advantage of keeping the family separate from the level, is that an
>> >old
>> >>application would still have a clue that a new level of document is
>really
>> >>an upwards compatible level with the enum that it understands, where as
>if
>> >>we register a new enum for each level, the old application will have no
>> >>clue
>> >>that the document is PostScript.
>> >>
>> >>For IPP, we might have a string, in which the family and level are
>> >>syntactially
>> >>distinguished, so that an old application could separate the family
>from
>> >>the level.
>> >>
>> >>In the Job Monitoring MIB we have the Printer MIB enum. But we might
>> >>change to the text string that has both family and level, if that is
>the
>> >>way that IPP goes. Then we wouldn't need to register the different
>levels
>> >>of PostScript and PCL.
>> >>
>> >>However, we may still want to register a PDF enum, since it is such a
>> >>common document format these days.
>> >>
>> >>We need some help here from Adobe and HP on what is the best course to
>> >>follow for the Printer MIB, Job Monitoring MIB, and IPP.
>> >>
>> >>I'd like to see this issue come up in the PWG agenda, since it affect
>> >>all three PWG progjects, if we can't resolve this via e-mail.
>> >>
>> >>Thanks,
>> >>Tom
>> >>
>> >>
>> >>See the current 1.5 or 1.6 IPP Model and Semantics.
>> >>
>> >>Here is the extracted text from that:
>> >>
>> >>5.2.7.1 document-format (type2Enumformat)
>> >>This job attribute identifies the document format of this document, and
>> >may
>> >>be a per-document attribute.
>> >>
>> >>This printer attribute indicates default value. It also indicates the
>> >>values
>> >>of the attribute supported by this printer and the states of readiness
>for
>> >>each value. One possible supported and default value is "auto-sense".
>> >>
>> >>The following standard values have been reviewed with the Printer
>Working
>> >>Group and are registered with IANA as part of the IETF Printer MIB
>> >project.
>> >>The token value assigned by the PWG starts with the four letters:
>"lang",
>> >>in
>> >>order to follow SNMP ASN.1 rules that all enum symbols shall start with
>a
>> >>lower case letter. The token values in IPP shall be the same as the
>IANA
>> >>token values, with the "lang" removed. The MIB (integer) value is
>> >included
>> >>here for reference only, the MIB value shall not be used in IPP; the
>> >token
>> >>value shall be used instead:
>> >>
>> >>Token Value MIB value Description
>> >> <<values deleted>
>> >
>> >
>> >
>>>>>>