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
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>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]
> *Sent:* Wednesday, January 27, 2010 3:29 PM
> *To:* William Wagner; 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> 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>
> 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>
>> 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/20100127/71291e39/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3457 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20100127/71291e39/attachment-0001.gif>
