Richard Shockey wrote:
>> I'm going to reply to this then remain silent again..
>> >
> >First, any law-making issues are WAY beyond the scope of any standard.
>> You might think that but you put printers on the Net and the first
> time some one tries to spam that printer ...I can tell guarantee you
> customers will start howling for security measures. I have
Yes, but that's an entirely different issue, and the forthcoming
1.1 spec (by requirement of the IETF) must have authentication in
it, which means access control. Sure, customers can turn this
functionality on and off, but THEY must take responsibility at some
point (we can only do so much).
> considerable evidence that if care is taken within the standard
> itself... the full protection of US Code 47.5.II, section 227 can be
> extended to all IPP transactions as they are for fax. That means
I'm not a lawyer so I can't say if this is valid or not. It would
at *least* require a court case or two to set this as a precedent.
> that you can sue someone for spaming your IPP printer. You want to
> sell this technology ..then giving it legal protection is important
> and standards bodies and the standards process can assist in that
> process.
No, it can't. The IETF (and every other "standards" body not given
regulatory rights by a government) can only define industry practice.
Law making and enforcement is under the control of the local/federal
governments. Hell, even the FCC can't make up new rules or
regulations without a law being passed by Congress!
> The simple fact is there is no difference between the LAN and the
> Net.. it just Lan's sit behind a fire wall.
Even that statement is inaccurate - a lot of (insert your opinion
here) companies connect to the Internet without firewalls.
> ...
> I submit there is no difference between general IPP printing and the
> general concept of "facsimile" printing... that said ..I did run a
> BOF on the issue a IETF Minneapolis.
If fax via IPP become recognized by the government (and you seem to
think it is/should be), then the requirements of fax over IPP become
much greater due to government regulation. These requirements go
beyond what is needed for general printing, and thus should not be
a requirement for standard IPP.
> I cannot imagine a network administrator who would not want to know
> who is using printing resources and WHEN.
The "time" parameters that are currently required (without the date
info) can provide the "when".
Also, don't expect many printers to implement job history or keep the
job history after powerdown.
> ...
> I would like for someone to confirm this ..but I believe that the
> cost of adding clock chips to printer devices is trivial. Fax
You're not thinking this through. It takes years to develop a new
printer, and adding an RTC clock adds to the complexity of the
design. Granted, it doesn't mean that it won't be cheap in the
long run, but with printers having an average product life of about
6 months these days, the cost is still pretty steep.
Also, that doesn't help for the millions (billions?) of printers
already out there. Most network printer vendors are adding firmware
upgrades that support IPP, but you can't upload a RTC chip over the
network...
> ...
> profit margins to the printer business, not requiring time/date
> responses for printers is being penny wise and pound foolish.
OK, you convince all of the printer vendors to add RTC chips to
every printer...
> The more IPP does to satisfy security as well as requirements
> time/date responses now, just makes the task of others in the future
> easier.
> ...
REQUIRING time/date responses will turn vendors away from IPP.
Defining them as optional (as a group) attributes that clients must
support will make "the task of others in the future easier".
Finally, any date/time information for faxing comes FROM THE SENDER
in conventional faxing anyways! Why should IFAX over IPP be any
different?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com