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@parc.xerox.com>
Organization: Xerox PARC
To: Randy Turner <rturner@sharplabs.com>
CC: ipp@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@lexmark.com
To: masinter@parc.xerox.com
Cc: ipp@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@parc.xerox.com>
Organization: Xerox PARC
To: ipp@pwg.org
Subject: Re: IPP> MIME-types and alignment
References: <33F03102.41C6@sharplabs.com> <33F891DB.8F095201@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@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@us.ibm.com>
To: <ipp@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@parc.xerox.com>
Organization: Xerox PARC
To: Harry Lewis <harryl@us.ibm.com>
CC: ipp@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@byas.com> To: ipp@pwg.org Subject: Re: IPP> MIME-types and alignment References: <33F03102.41C6@sharplabs.com> <33F891DB.8F095201@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@byas.com> To: Bill Wagner <bwagner@digprod.com> CC: ipp@pwg.org Subject: Re: IPP> MIME-types and alignment References: <00022E40.1337@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@lexmark.com, masinter@parc.xerox.com From: Carl-Uno Manros <cmanros@cp10.es.xerox.com> Subject: Re: IPP> MIME-types and alignment Cc: ipp@pwg.org In-Reply-To: <199708181914.AA23694@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@cp10.es.xerox.com
************************************************************************ ************************************************************************ From: Roger K Debry <rdebry@us.ibm.com> To: <ipp@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@us.ibm.com phone: 1-303-924-4080
************************************************************************ ************************************************************************ Date: Tue, 19 Aug 1997 07:23:43 PDT To: Roger K Debry <rdebry@us.ibm.com>, <ipp@pwg.org> From: Carl-Uno Manros <cmanros@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@cp10.es.xerox.com
************************************************************************ ************************************************************************ Date: Tue, 19 Aug 1997 18:18:23 -0400 From: bwagner@digprod.com (Bill Wagner) Subject: Re[2]: IPP> MIME-types and alignment Cc: ipp@pwg.org
In reply to:
Subject: Re: IPP> MIME-types and alignment Author: AlBrahme <albrahme@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@us.ibm.com> To: <masinter@parc.xerox.com> Cc: <pmp@pwg.org>, <ipp@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@us.ibm.com> To: <ipp@pwg.org> Cc: <pmp@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@parc.xerox.com> Organization: Xerox PARC To: Harry Lewis <harryl@us.ibm.com> CC: pmp@pwg.org, ipp@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@lexmark.com To: masinter@parc.xerox.com Cc: Harryl@Us.Ibm.Com, Pmp@pwg.org, Ipp@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@us.ibm.com> To: <don@lexmark.com> Cc: <pmp@pwg.org>, <ipp@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@us.ibm.com> To: <masinter@parc.xerox.com> Cc: <pmp@pwg.org>, <ipp@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==_============--