Hi,
Jerry - to address your specific concerns:
(1) Currently IANA Printer MIB includes
- langPCL(3)
- langHPGL(4)
- langPJL(5)
- langPS(6)
- langPCLXL(47)
- langPDF(54)
(2) IANA is very responsive (days) about
registering new values, so adding (for
example) langPDFis, langPS2, langPDF4,
etc., is feasible and practical.
I suggest that registering new values with
IANA is preferable to a (probably not
interoperable) optional use of version
suffixes.
I agree that the Genuine versus Emulation
issue is important for product claims and
for customers - I just don't think we should
try to shoehorn it into IEEE 1284 Device ID.
Bill - due to repeated changes of our mail
server, PWG Steering Committee decided
several years ago to only put this generic
reference to mailing list subscription info
in our specs:
http://www.pwg.org/mailhelp.html
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Thu, Jan 28, 2010 at 10:22 AM, Jerry Thrasher <thrasher at lexmark.com>wrote:
>> Re the questions that were raised (not to the point of last call comments
> but I guess they should be discussed)
>> The question about distinguishing the difference between an Emulation and
> "Genuine" is not a concern
> about interoperability, but if there is a legal requirement to make the
> distinction. We are checking on the
> history of this "requirement" internally, if others on the list have an
> opinion, please share.
>> The question about distinguishing versions of PDLs really comes down to the
> user experience, and if
> the potential interoperability issues are acceptable to those who want to
> parse the string. I'd like to hear
> Mike Sweet's take on this. Specific examples of this are fairly easy to
> cite.
>> (If a device only supports PCL 3, but simply advertizes PCL, and is sent a
> PCL 5 or 6 job that uses HP-GL2 from the host,
> there will be interoperability problems)
> (Another variant on the versioning issues is if a device only supports PDF
> I/S, and only advertizes PDF, and is sent PDF V4,
> there may be memory issues with processing the job.)
>> A very quick scan of vendor web pages and their claimed PDL support .
>> Lower end inkjet printers and MFDs support, HP PCL 3 GUI, HP PCL 3 Enhanced
>> Lower end lasers that support "standard PDLs" support, Postscript 3, PCL 6,
> PCL 5e
>> (Sample from four different vendor web sites, all with list prices under
> $300.00 USD)
>> _____________________________________
>> [image: LEXMARK] *
> Jerry Thrasher*
> Senior Engineer, WW Corporate Standards
> C14/082-1, 740 New Circle Rd, Lexington Ky 40550
> Office: +1 859 825 4056 Fax: +1 859 232 7628
> thrasher(at)lexmark(dot)com
>>> *"William Wagner" <wamwagner at comcast.net>*
>> 01/27/2010 09:01 PM
> To
> "'Ira McDonald'" <blueroofmusic at gmail.com>
> cc
> <wims at pwg.org>, "'Jerry Thrasher'" <thrasher at lexmark.com>
> Subject
> RE: [PDL versions?] PWG last call - Command Set Format - IEEE1284
> Device ID -25 Feb 2010
>>>>> Hi Ira,
>> Understood … but I believe it is more polite to ask permission before
> posting to the list emails sent privately.
>> I simply suggested that, to satisfy the requirements you listed in the
> document, it is necessary to be able to understand what the PDL is, and
> because there are differences in emulations and versions, it may be
> necessary that the reader be aware of the emulation or version. If there is
> no way of providing this information, then interpreter either has to deal
> with a PDL that is not quite what it says it is, or it has another private
> PDL to accommodate. In either case, the underlying objective of the
> specification is compromised. Currently, although the string may not be as
> machine readable as desired, that information about version and emulation is
> available.
>> I believe that these are valid points to be considered both by printer
> manufacturers and those reading the string. It may well be that, rather than
> provide incomplete information, it would be better to use the current
> approach.
>> Bill Wagner
>> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com] *
> Sent:* Wednesday, January 27, 2010 8:13 PM*
> To:* William Wagner; Ira McDonald*
> Cc:* wims at pwg.org; Jerry Thrasher*
> Subject:* Re: [PDL versions?] PWG last call - Command Set Format -
> IEEE1284 Device ID -25 Feb 2010
>> Hi Bill,
>> [please read the mail headers in this thread]
>> I already PUT it on the WIMS WG mailing list - because ALL
> PWG Last Call comments are supposed to be publicly posted
> and archived.
>> I do not find any basis for document format variants in the
> requirements you quoted.
>> And the basic method (using Printer MIB enum labels) has
> been unchanged (and unchallenged) ever since Mike Sweet
> originally proposed this standard at the Open Printing Summit
> in Montreal in fall 2007 and the PWG SC agreed to look into
> it (i.e., it became my long-standing action item).
>> This interoperable labeling of document format variants (which
> is NOT possible in Printer MIB) is a major new requirement.
>> Allowing document format variant labeling may be possible
> with some suffix syntax, but *interoperable* document format
> variant labeling is simply impossible.
>> Vendors don't currently use the same version numbers to
> mean the same thing, and it's way out-of-scope for this
> specification to solve *that* problem.
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> email: *blueroofmusic at gmail.com* <blueroofmusic at gmail.com>
> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>> On Wed, Jan 27, 2010 at 5:41 PM, William Wagner <*wamwagner at comcast.net*<wamwagner at comcast.net>>
> wrote:
> Do either of you object if we put this on the PMP/WIMS mailing list and
> include it in the face-to-face discussion?
>> With respect to Ira’s comments, one may argue that design requirements 5-7
>> · should support automatic device driver installation by client
> and server operating systems (see section 3.2).
>> · should support interoperable advertising of implemented document
> formats by network spoolers and network Printers (see sections 3.1 and 3.2).
>> · should support interoperable discovery of available document
> formats by Imaging Clients and Imaging Servers (see sections 3.1 and 3.2).
>> would suggest a document format method that did distinguish between
> variations on a language without the need for creating a slew of
> vendor-specific language identifications.
>>>> Thanks,
>>>> Bill Wagner
>> *From:* Ira McDonald [mailto:*blueroofmusic at gmail.com*<blueroofmusic at gmail.com>]
> *
> Sent:* Wednesday, January 27, 2010 3:29 PM*
> To:* William Wagner; *wims at pwg.org* <wims at pwg.org>; Ira McDonald*
> Cc:* Jerry Thrasher*
> Subject:* Re: [PDL versions?] PWG last call - Command Set Format -
> IEEE1284 Device ID -25 Feb 2010
>> Hi Jerry,
>> The short answers to your questions are:
>> (1) Distinguishing Emulation from Genuine was not a
> design objective.
>> (2) Distinguishing PDL versions was also not a design
> objective (or plausibly interoperable).
> - The use and misuse of the corresponding version
> elements in the Printer MIB v1/v2 prtInterpreterTable
> is a hopeless mess.
> - Nobody was willing to let the editors to address this
> when we did Printer MIB v2.
>> So, inserting version information may work for a given
> vendor, but completely breaks interoperability across
> different spoolers and OS environments.
>> We could perhaps introduce a syntax for version
> suffixes, but the chances that vendors will correctly
> implement it seems very unlikely.
>> Bearing in mind the machine-readability imperative,
> do you have an interoperable version suffix format
> to propose?
>> Or an interoperable Emulation versus Genuine suffix
> format?
>> Cheers,
> - Ira (1284 Cmd Set editor)
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> email: *blueroofmusic at gmail.com* <blueroofmusic at gmail.com>
> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
> On Wed, Jan 27, 2010 at 11:58 AM, William Wagner <*wamwagner at comcast.net*<wamwagner at comcast.net>>
> wrote:
> Hi Jerry,
>> I am sending your questions onto Ira. I think your two points are very good
> ones. My take on them:
>> The spec allows for PrtInterpreterLangFamilyTC, mime-media-type, and Private
> type designations. PrtInterpreterLangFamilyTC does not provide for version
> and emulation variations; mime-types for all of the variations do not exist,
> and would be cumbersome if they were to be all registered; and having
> applications understand the difference between private types is unrealistic.
>> The intent is machine identification of the command language. Just
> indicating (by an appropriate means… placing “emulation” after the
> designation does not appear consistent with the spec) that a pdl is an
> emulation warns the interpreter that there may be differences from the
> defined set, but these will likely be different from one emulation to
> another. I think the best approach depends on how good the emulation is (as
> an emulation, not as a PDL). But, barring having to define and designate
> each emulation as a separate PDL, there might be some benefit in somehow
> flagging that a PDL might deviate somewhat from the defined language.
>> Major Version differences are likely more drastic, more likely to be
> independently defined and since there should be fewer of them that possible
> emulations, more amenable to being listed as separate MIB or MIME types.
> That is, there is little advantage in knowing the language is up-version
> (other than expecting differences) unless the interpreter knows what the
> differences are. To be able to do this, the version and its definitive
> reference should be identified in a standard way. The problem then, of
> course, is who is going to register these versions.
>> Thanks for the input.
>> Bill Wagner
>>>> *Jerry Thrasher/Lex/Lexmark*
>> 01/27/2010 09:07 AM
>> To
> "William Wagner" <*wamwagner at comcast.net* <wamwagner at comcast.net>>
> cc
> Subject
> Re: [Pwg-Announce] PWG last call - Command Set Format - IEEE1284 Device
> ID -25 Feb 2010
>>>>>>> Bill,
>> A couple of questions have come up with respect to what's really required
> to be done and what
> can be done with respect to two particular issues.
> 1. The percieve requirement for not confusing PDL emulation with "true" PDL
> support
> Example, Postscript Emulation vs. Adobe PostScript and PCL Emulation vs. HP
> PCL support.
> 2. The need for the ability for versioning of the various PDLs.
> PCL 6 is very different from PCL 3 (most low end inkjet printers still
> support only PCL 3, the first
> PCL to support color).
>> So here's what I'm talking about from a real string.
> Example:
> If the current CMD string is:
>> COMMAND SET:PCL 6 Emulation, PostScript Level 3 Emulation, NPAP, PJL;
>> Would a compliant string simply be:
>> COMMAND SET:PCL,PS,PCL 6 Emulation, PostScript Level 3 Emulation, NPAP,
> PJL;
>> _____________________________________
>> [image: LEXMARK] *
> Jerry Thrasher*
> Senior Engineer, WW Corporate Standards
> C14/082-1, 740 New Circle Rd, Lexington Ky 40550
> Office: +1 859 825 4056 Fax: +1 859 232 7628
> thrasher(at)lexmark(dot)com
>>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/wims/attachments/20100128/969b9491/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3457 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20100128/969b9491/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3457 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20100128/969b9491/attachment-0003.gif>
