--============_-1339818960==_============
Content-Type: text/plain; charset="us-ascii"
ACTION REQR'd by 9/3
There was a relative small turn-out on the August 20 IPP Phone call. The
primary topics of discussion were MIME-types and prtInterpreterLangFamily
and Job-ID. Because so many of the regular participants will be at the
briefing in Boston and may be leaving for airplanes, the August 27th phone
call has been cancelled. You are asked, however, to participate in the
September 3 phone call if you care about how the resolution of either of
the above to issues. We hope to close all outstanding issues during that
phone call.
With respect to MIME-types and prtInterpreterLangFamily,
There was a useful discussion of this topic both on the mailing list
(digest of which is attached) and on the Weekly Phone meeting on Aug
20. I would summarize the current position as follows
For IPP:
IPP is strongly encouraged (read, the draft will have GREAT difficulty
getting throught the IESG without it) to use MIME-types to identify the
document format.
The main reason for this request is that using a MIME-type solves more
problems than does using the prtInterpreterLangFamily enum. For example,
1. Many protocols, including HTTP, use the MIME-type to identify the
format of a "file." (Here "file" can be a file or a segment of a
multipart message, etc.).
2. Some text based file formats, e.g., PCL, require that the character
set used to represent the text be identified. Using MIME-types allows a
character set parameter to be attached to the MIME-type.
As an example of the utility of 1. consider an application that is
generating a PostScript file. This file may or may not be printed; for
example, it may be intended for input into a PDF distiller. The
application (which may not know the intended use of the file) would not
be able to label the file if Printers use a different label from other
applications. (Yes, of course, the label does not necessarily go on the
file, but, more often, on/in the message by which the file is
transmitted. But, with a "standard" labelling scheme, the type label may
work its way into file system directory information.)
The reasons for using the prtInterpreterLangFamily enum seem to be:
1. The printer MIB uses it and we wish to align IPP with the Printer MIB so
that no matter which path you get information from the Printer, it comes
out the same where the same question can be asked (e.g., what languages
does this Printer support, right now).
2. The prtInterpreterLangFamily enum has already been populated with the
relevant languages, why is is necessary to do this work all over again?
These reasons are relevant, but not strictly compelling, IMHO. Consider
the following proposal:
The Printer MIB retains the prtInterpreterLangFamily object and adds a
new object prtInterpreterLangFamilyMIMEtype. The use of the first
object is Deprecated, but not Obsoleted. The MIME-type registry is
updated to have all the types that are in the prtInterpreterLangFamily
enum registry. A new value is added to the prtInterpreterLangFamily enum
registry. This value stands for "There is no prtInterpreterLangFamily
enum assigned so use the prtInterpreterLangFamilyMIMEtype value
instead". (Note this could be a new value or it could be an action taken
when the "Unknown" value of the prtInterpreterLangFamily enum is seen.)
This allows future formats to be registered only in the MIME-type list
and to provide a way to tell a MIB client that it should use the
prtInterpreterLangFamilyMIMEtype value instead of the
prtInterpreterLangFamily value.
Since it is not the function of the IPP maillist to design the Printer
MIB, the above is provided as a suggestion for a way to keep IPP and the
Printer MIB aligned. With this proposal, the Printer MIB grows by one
object (and a somewhat bulky table of character strings for the
MIME-types), but preserves interoperability with the existing MIB
clients and agents. This seems like a small price to pay for
interoperability both between the Printer MIB and IPP and IPP and the
other application protocols.
Note there was some (useless) noise in the message log that appeared to
be disparaging the reality of the Printer MIB. When the smoke cleared, I
believe the only assertion being made was that it appeared that
MIME-types had a wider (current) deployment than
prtInterpreterLangFamily enum values. Therefore, if we were to
*standardize on only one of these*, the use of MIME-type would affect the
smaller number of "affectees". Those of us doing printers make up most
of those "affectees", however. I do not believe that people would
disagree with the above conclusion, but I do believe that people might
not agree that we need to have *only one standard*.
Assuming that the WG agrees to use MIME-types for Document Format in IPP
(and, separately, the Printer MIB group adds the
prtInterpreterLangFamilyMIMEtype object) then the following work items
arise:
1. The MIME-type registration must be updated to add all the
prtInterpreterLangFamily values that are currently not in the MIME
registry. Note that the MIME registry has at least two sub-trees: the
IETF subtree and the Vendor sub-tree. Types may be registered in the
IETF only via a standards track RFC (IPP is one of these, Printer MIB is
another). Types may be registered in the Vendor sub-tree by any
vendor. Besides requiring an RFC to register, registration in the IETF
sub-tree also requires "a precise and openly available specification of
the format." No specification is required for the Vendor sub-tree, but a
specification is "encouraged". Therefore, a decision must be made for
the unregistered prtInterpreterLangFamily enums. This memo suggests that
they be registered in the Vendor sub-tree using the information
currently in the prtInterpreterLangFamily enum registry. This
registration is best done by the company owning the format so that a
request to this effect will be sent to the contact point in the
prtInterpreterLangFamily registry; if this fails to produce a
registration, then the the IPP RFC will force the registratration.
2. The prtInterpreterLangFamily enum registry should be updated to
include a new line for the MIME-type. This would be the already
registered MIME-type where there is one already and would be the one
registered by step 1. above where it was not registered.
--============_-1339818960==_============
Content-Type: text/plain; name="MIME-type"; charset="us-ascii"
Content-Disposition: attachment; filename="MIME-type"
Date: Mon, 18 Aug 1997 11:18:03 PDT
From: Larry Masinter <masinter at parc.xerox.com>
Organization: Xerox PARC
To: Randy Turner <rturner at sharplabs.com>
CC: ipp at pwg.org
Subject: IPP> MIME-types and alignment
> It was the opinion of Larry Masinter (chair of HTTP WG), Keith
> Moore, and most of the IETF audience that alignment with the
> Printer MIB was a mistake, and that we should focus on sticking
> with MIME-type specifications.
To be more precise:
When IPP is being used for transporting a message (document, print
instructions) from a willing sender to a willing recipient, alignment
with other widely implemented and deployed Internet protocols for
message transmission (mail, fax, Web) is more useful than alignment with
some hypothetical and not widely deployed protocol for system management
and monitoring of the status of a device.
************************************************************************
************************************************************************
From: don at lexmark.com
To: masinter at parc.xerox.com
Cc: ipp at pwg.org
Date: Mon, 18 Aug 1997 15:14:30 -0400
Subject: Re: IPP> MIME-types and alignment
I contend that when the latest and in some cases the previous
versions of printers from Lexmark, HP, IBM, Kyocera, Tektronix,
and Xerox support the printer MIB including the enum list of
printer interpreters then it is not simply "hypothetical" nor is
it "...not widely deployed..."
I suggest you might not want to base your conclusions on this
obviously wrong set of facts.
Don
************************************************************************
************************************************************************
Date: Mon, 18 Aug 1997 13:21:08 PDT
From: Larry Masinter <masinter at parc.xerox.com>
Organization: Xerox PARC
To: ipp at pwg.org
Subject: Re: IPP> MIME-types and alignment
References: <33F03102.41C6 at sharplabs.com> <33F891DB.8F095201 at parc.xerox.com>
I was criticized sharply for saying:
> When IPP is being used for transporting a message (document, print
> instructions) from a willing sender to a willing recipient, alignment
> with other widely implemented and deployed Internet protocols for
> message transmission (mail, fax, Web) is more useful than alignment with
> some hypothetical and not widely deployed protocol for system management
> and monitoring of the status of a device.
and stand corrected. I wish to remove the word "hypothetical" and
insert the word "as" before "widely deployed", since there have been
many printers that support the printer MIB.
However, I would like to inquire if there are clients of printer MIBs
that use the enum list of printer interpreters for anything other
than displaying to the user of a system monitoring device for
informational
display, i.e., whether the protocol use within printer MIB could be
replaced with a comment string without affecting the operational
stability of any application.
Larry
************************************************************************
************************************************************************
Date: Mon, 18 Aug 1997 16:28:13 -0400
From: bwagner at digprod.com (Bill Wagner)
Subject: Re: IPP> MIME-types and alignment
The precisely stated position is interesting. But should it not be
considered that this protocol is intended to be used not so much by
Mail, Fax and Web but by those devices for which that "hypothetical
and not widely deployed protocol for system management and monitoring"
has been developed. And indeed, I think you would find that the
Printer MIB is hardly hypothetical and is implemented in a majority of
the printers sold today. It would appear that unnecessary
compatibility is regarded as critical at the expense of adding a
separate and currently incomplete emulation coding scheme in the
hardware.
It should be noted that previous investigations intended to bring the
MIME registry up to the point of being able to sufficiently identify
printer languages have been given up as too major an effort with too
little benefit.
Bill Wagner, Osicom/DPI
************************************************************************
************************************************************************
From: Harry Lewis <harryl at us.ibm.com>
To: <ipp at pwg.org>
Subject: Re: IPP> MIME-types and alignment
Date: Mon, 18 Aug 1997 19:56:16 -0400
I can't tell who originated this mail message...
>To be more precise:
>>When IPP is being used for transporting a message (document, print
>instructions) from a willing sender to a willing recipient, alignment
>with other widely implemented and deployed Internet protocols for
>message transmission (mail, fax, Web) is more useful than alignment with
>some hypothetical and not widely deployed protocol for system management
>and monitoring of the status of a device.
but the author misrepresents the fact that Printer MIB Interpreter Languages
are enumerated in the MIB and registered with IANA (on recommendation of
the IETF) to support knowledge of the CAPABILITIES and default configuration
of the printer - especially the notion of a default PDL for a print "channel"
or a means of printing to the device. I believe this is similar to the
requirements of IPP. I'm not arguing against MIME registration of PDLs for
IPP (I don't see why we shouldn't facilitate both MIME and enums).
Also, I think characterization of the Printer MIB as not widely deployed
is subjective (and somewhat misinformed) and could be harmful to those who
have worked hard to support this standard if it came from an "IETF official".
If nothing else, it might help explain some of the "jitters" we've seen lately
from the IESG with respect to aligning standards in the world of print.
Harry Lewis
************************************************************************
************************************************************************
Date: Mon, 18 Aug 1997 17:30:09 PDT
From: Larry Masinter <masinter at parc.xerox.com>
Organization: Xerox PARC
To: Harry Lewis <harryl at us.ibm.com>
CC: ipp at pwg.org
Subject: Re: IPP> MIME-types and alignment
Harry, you must have missed my retraction. Clearly what I meant to say
was that the Printer MIB isn't _as_ widely deployed [as web servers
and browsers and MIME email senders and recipients].
> the author misrepresents the fact that Printer MIB Interpreter Languages
> are enumerated in the MIB and registered with IANA (on recommendation of
> the IETF) to support knowledge of the CAPABILITIES and default configuration
> of the printer - especially the notion of a default PDL for a print "channel"
> or a means of printing to the device.
Since you must be speaking from some better knowledge of the situation,
can you give any examples of clients that actually use the Printer MIB
Interpreter Languages to make some useful decision (as opposed to, say,
just displaying the information)?
Regards,
Larry
--
http://www.parc.xerox.com/masinter
************************************************************************
************************************************************************
Date: Mon, 18 Aug 1997 18:39:07 +0000
From: AlBrahme <albrahme at byas.com>
To: ipp at pwg.org
Subject: Re: IPP> MIME-types and alignment
References: <33F03102.41C6 at sharplabs.com> <33F891DB.8F095201 at parc.xerox.com>
Larry Masinter wrote:
> When IPP is being used for transporting a message (document, print
> instructions) from a willing sender to a willing recipient, alignment
> with other widely implemented and deployed Internet protocols for
> message transmission (mail, fax, Web) is more useful than alignment with
> some hypothetical and not widely deployed protocol for system management
> and monitoring of the status of a device.
I like this idea. Earlier i tried to get TIFF-F (for fax) included in
the printer
mib but did not get much support. But if IPP is going to be aligned
with
MIME that will solve the problem since TIFF-F will be assigned a MIME
type
anyway.
/al
************************************************************************
************************************************************************
Date: Mon, 18 Aug 1997 18:58:22 +0000
From: AlBrahme <albrahme at byas.com>
To: Bill Wagner <bwagner at digprod.com>
CC: ipp at pwg.org
Subject: Re: IPP> MIME-types and alignment
References: <00022E40.1337 at digprod.com>
Bill Wagner wrote:
>> It should be noted that previous investigations intended to bring the
> MIME registry up to the point of being able to sufficiently identify
> printer languages have been given up as too major an effort with too
> little benefit.
>
Well, what about the reverse? How will printer MIB be updated to
include
MIME types?
/al
************************************************************************
************************************************************************
Date: Tue, 19 Aug 1997 02:21:18 PDT
To: don at lexmark.com, masinter at parc.xerox.com
From: Carl-Uno Manros <cmanros at cp10.es.xerox.com>
Subject: Re: IPP> MIME-types and alignment
Cc: ipp at pwg.org
In-Reply-To: <199708181914.AA23694 at interlock2.lexmark.com>
Don,
during the Application Area Chairs'' meeting in Munich last Wednesday, I
asked Keith to amplify on his request to use MIME types rather than enums.
This resulted in Keith stating that we should see this as a directive from
him in his role as our project advisor.
My interpretation is that it does not seem likely that we will be able to
avoid the MIME-types.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
************************************************************************
************************************************************************
From: Roger K Debry <rdebry at us.ibm.com>
To: <ipp at pwg.org>
Subject: Re: IPP> MIME-types and alignment
Date: Tue, 19 Aug 1997 09:54:04 -0400
If we take Keith's direction, do we need to register new MIME types
to represent all of the PDLs currently in the model document? Who
owns the responsibility to do this?
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
************************************************************************
************************************************************************
Date: Tue, 19 Aug 1997 07:23:43 PDT
To: Roger K Debry <rdebry at us.ibm.com>, <ipp at pwg.org>
From: Carl-Uno Manros <cmanros at cp10.es.xerox.com>
Subject: Re: IPP> MIME-types and alignment
In-Reply-To: <5030100006611933000002L032*@MHS>
At 06:54 AM 8/19/97 PDT, Roger K Debry wrote:
>If we take Keith's direction, do we need to register new MIME types
>to represent all of the PDLs currently in the model document? Who
>owns the responsibility to do this?
>>Roger K deBry
I expect that we need to take on the job, we may potentially want to
depricate some which are not in use any more. Alternatively, the companies
that own the various formats could be asked to do their own, but this could
take quite a while.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
************************************************************************
************************************************************************
Date: Tue, 19 Aug 1997 18:18:23 -0400
From: bwagner at digprod.com (Bill Wagner)
Subject: Re[2]: IPP> MIME-types and alignment
Cc: ipp at pwg.org
In reply to:
Subject: Re: IPP> MIME-types and alignment
Author: AlBrahme <albrahme at byas.com> at Internet
Date: 8/18/97 6:58 PM
>>It should be noted that previous investigations intended to bring
>>the MIME registry up to the point of being able to sufficiently
>>identify printer languages have been given up as too major an
>>effort with too little benefit.
>Well, what about the reverse? How will printer MIB be updated to
>include MIME types?
Al:
It is my undersanding that the printer MIB prtInterpreterLangFamily
enumerations of printer page description languages are type 2
enumerations, and that the registry is maintained by IANA. By my
recall, a request may be submitted to the PWG identifying the name of
the language, a brief description, an identification of the owner and
a reference to the definitive document describing it. It would also be
desirable to provide information to be included in the
prtInterpreterLangLevel and prtInterpreterLangVersion fields.
I did not follow the specific thread that evidentally caused your
problem with TiffF, but it should be noted that langTIFF(40) has long
been included in the Printer MIB. If TiffF represents a new family, it
should be accepted as such. If it repersents a new level and/or
version, then there would appear no need to get a new enumeration.
The method of identifying languages, although less than perfect,
appeared to best address the constraints of the printer companies who
owned and used these languages. This process was not developed
arbitrarily and there have been several attempts in the past to make
the registry more uniform and usable. There have also been volunteers
who were going to re-register all of the combinations in MIME... but
for some reason they have not been heard from for some time.
I suspect that the PWG has no objection to using or including MIME
encoding, but in past it has found such coding inappropriate. I would
also observe that, because of the tight cost constraints on printers,
there has been an attempt to minimize long text string objects. And
with regard to the suggestion that less popular languages need not be
included, that does not seem to be in the spirit of providing
compatability with the existing equipment base.
Bill Wagner, Osicom/DPI
************************************************************************
************************************************************************
From: Harry Lewis <harryl at us.ibm.com>
To: <masinter at parc.xerox.com>
Cc: <pmp at pwg.org>, <ipp at pwg.org>
Subject: Re: IPP> MIME-types and alignment
Date: Tue, 19 Aug 1997 19:20:32 -0400
Larry, you inquired...
>However, I would like to inquire if there are clients of printer MIBs
>that use the enum list of printer interpreters for anything other
>than displaying to the user of a system monitoring device for
>informational display, i.e., whether the protocol use within printer
>MIB could be replaced with a comment string without affecting the
>operational stability of any application.
Printer discovery may be coupled with programmatic use of the Interpreter
table to facilitate selection of the correct driver in a printing system.
Also, there are disadvantages to MIME for memory constrained systems
(typical devices or end-nodes). An integer representation is much more
concise and alleviates storing translations. Granted, most PDL names
are not likely to require translation but I'm not entirely certain for
all of them (use "PAGES" as an example").
Harry Lewis
************************************************************************
************************************************************************
From: Harry Lewis <harryl at us.ibm.com>
To: <ipp at pwg.org>
Cc: <pmp at pwg.org>
Subject: Re: IPP> MIME-types and alignment
Date: Tue, 19 Aug 1997 19:40:10 -0400
Someone wrote:
> Earlier i tried to get TIFF-F (for fax) included in the printer
> mib but did not get much support.
>> /al
I don't recall the TIFF-F request, but, if someone has a PDL to
register as a type-2 enum with the Printer MIB, it should require
very little effort and should not meet with a great deal of
resistance.
For example,the following requests from Jeff Rackowitz were readily
accepted:
langIntermecIPL(56), -- Intermec Printer Language for label printers.
-- Technical Manual: "IPL Programmers Reference
-- Manual",
-- Intermec Corporation
langUBIFingerprint(57), -- An intelligent basic-like programming
-- language for label printers.
-- Reference Manual: "UBI Fingerprint
-- 7.1", No. 1-960434-00
-- United Barcode Industries
langUBIDirectProtocol(58), -- An intelligent control language for
-- label printers.
-- Programmers guide: " UBI Direct
-- Protocol", No. 1-960419-00
-- United Barcode Industries
The Printer MIB type-2 enum process is meant to assure adequate information
during registration and to possibly filter redundancy... not to reject
legitimate requests.
I searched the PMP archives and could not find a reference to your request
for TIFF-F. Perhaps you should re-submit it, using the sample, above, as
a template.
Harry Lewis
************************************************************************
************************************************************************
Date: Wed, 20 Aug 1997 04:39:54 PDT
From: Larry Masinter <masinter at parc.xerox.com>
Organization: Xerox PARC
To: Harry Lewis <harryl at us.ibm.com>
CC: pmp at pwg.org, ipp at pwg.org
Subject: Re: IPP> MIME-types and alignment
I asked:
> I would like to inquire if there are clients of printer MIBs
> >that use the enum list of printer interpreters for anything other
> >than displaying to the user of a system monitoring device for
> >informational display
and you answered with a hypothetical ("may be") rather than an actual
("is, in the following product"):
> Printer discovery may be coupled with programmatic use of the
> Interpreter table to facilitate selection of the correct driver
in a printing system.
I understand clearly how it could be used, what I'm asking is whether
it *is* used. Isn't it a misuse of SNMP to use it for discovery. Are
there systems that actually use the Printer MIB, rather than some kind
of directory service, for device discovery?
> Also, there are disadvantages to MIME for memory constrained systems
> (typical devices or end-nodes). An integer representation is much
> more concise and alleviates storing translations.
I find this incredible: an end-node has enough memory to hold the
4 bytes for an integer enumeration, but not enough to hold
the string "application/postscript"? I don't know what you mean
by 'storing translations'. MIME types are protocol elements, and
not user strings.
> Granted, most PDL names are not likely to require translation
> but I'm not entirely certain for all of them (use "PAGES" as
> an example").
MIME types are not "PDL names". They are registered strings instead
of registered entities.
The issue is not the advantage of form, the issue is that we need
a single registry of media types, so that we don't have to coordinate
parallel registries or deal with the consequences of not doing so.
Larry
************************************************************************
************************************************************************
From: don at lexmark.com
To: masinter at parc.xerox.com
Cc: Harryl at Us.Ibm.Com, Pmp at pwg.org, Ipp at pwg.org
Date: Wed, 20 Aug 1997 08:03:51 -0400
Subject: IPP> PMP> MIME-types and alignment
In my mind, clearly the issue on this subject is the current status
of the Printer MIB. This project has been in existence since 1993
(perhaps not formally but in reality.) We have taken the advise
of our first advisor and our current advisor and used the most
common methods employed in all the MIBs I have seen and
that is an enumerated list. At this point in time we have a number
of products that ship today with RFC1759 support including
both printers and printer management application. Obviously,
both support this enumerated list of interpreters. As far as the
question of whether or not applications use this interpreter list
to make the determination of which datastream to send, I believe
it is too early to answer. Remember, the MIB is currently is in
the proposed state. In many case in the management area,
implementations of proposed RFC's are never shipped as
products, they are simply prototyped. This is a different
philosophy from what has been done in the applications
area.
In the process of progressing the Printer MIB from proposed to
draft we have very carefully and meticulously identified the
things we have learned in the implementation of the above
mentioned products and in the interoperability testing that
was performed. At no time and in no way is there implementation
experience or testing that justifies a major change in the printer
MIB to move from an enumerated list of printer interpreters to
MIME. In many cases, the interpreters are listed in ways that
are specific to printer utilization. In several cases and for very
specific and understood reasons, control methods such as
PJL and IEEE 1284.1 have been included as interpreters.
Additionally we have included things like "Automatic" which
implies an intelligence in the printer to determine the printer
datastream. (I really thing a MIME type of application/automatic
might be a little hard to justify and define.)
I think at this point in time, to throw away what we learned because
the current hot button for HTTP and e-mail systems is the
use of MIME and try to graft it onto a MIB that we have already
proven to work and that is progressing based upon the needs
of the printer and printing management community is wrong.
Perhaps de-coupling IPP from the MIB in this area could be
justified but changing the MIB is simply not appropriate and is
not justified.
Don
************************************************************************
************************************************************************
From: Harry Lewis <harryl at us.ibm.com>
To: <don at lexmark.com>
Cc: <pmp at pwg.org>, <ipp at pwg.org>
Subject: IPP> Re: PMP> MIME-types and alignment
Date: Wed, 20 Aug 1997 11:10:37 -0400
Don, thanks for your excellent summary. Very well put!
It is not at all reasonable to entertain the notion of ripping
prtInterpreterLangFamily enums out of the Printer MIB. Whether
or not to *also* register some of the same PDL's as MIME types
for use in IPP is a separate question. I think Larry has eluded
to the inevitable double registry and, by the way, several PDLs
can already be found in both places. Since the Printer MIB enums
are type-2, any new MIME type ("PZL7 Version 5.53" - hypothetical)
can easily be assigned an enum. A simple mapping document from
MIME to enum would be a useful tool which the PWG could maintain.
The key question still is which method of referencing PDLs will work
best for IPP - and why.
Harry Lewis - IBM Printing Systems
************************************************************************
************************************************************************
From: Harry Lewis <harryl at us.ibm.com>
To: <masinter at parc.xerox.com>
Cc: <pmp at pwg.org>, <ipp at pwg.org>
Subject: Re: IPP> MIME-types and alignment
Date: Wed, 20 Aug 1997 17:00:04 -0400
Larry... you are concerned that
>I asked:
>>> I would like to inquire if there are clients of printer MIBs
>> >that use the enum list of printer interpreters for anything other
>> >than displaying to the user of a system monitoring device for
>> >informational display
>>and you answered with a hypothetical ("may be") rather than an actual
>("is, in the following product"):
When you insinuate that an application using prtInterpreterLangFamilyTC
programmatically or coupling knowledge of the Printer MIB with discovery
is a "misuse" of SNMP, then ask for public disclosure and names of
applications that do so, please don't interpret lack of response as
resolution to the concern.
I will assume that this context developed, unintentionally, out of
enthusiastic quest for closure to the discussion, and try to
answer your question in a more straightforward manner.
People will tend to use what is defined and what works. There
is currently no more widely embraced Internet standard related
to printing than the Printer MIB. It is perfectly feasible to use
this standard MIB as part of a scheme to discover printer
capabilities and make programmatic choices based on what is
found and ... yes... there are products which do this today.
I own some of them and I am aware of at least one other source
of applications utilizing this practice - I suspect there are more.
Harry Lewis
************************************************************************
************************************************************************
--============_-1339818960==_============--