Here are some answers to your questions...
> ----------
From: Tom Hastings[SMTP:hastings@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@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@cp10.es.xerox.com]
> >>Sent: Thursday, March 13, 1997 1:31 PM
> >>To: pmp@pwg.org; ipp@pwg.org; jmp@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>
> >
> >
> >