IPP> MOD - part of Issue 17 - don't neednegative"time-at-xxx" Job Attributes

IPP> MOD - part of Issue 17 - don't neednegative"time-at-xxx" Job Attributes

Richard Shockey rshockey at ix.netcom.com
Thu Apr 29 12:55:28 EDT 1999



>> 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.

Yes, of course...and I think we have a opportunity to set the preconditions
for that see below.

>> 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!


Well... standards bodies have a considerable influence on the courts and
regulatory bodies here in the US and in other countries as well.  The
general principal is this. The courts and the FCC here in the US are quite
aware that technology marches on and often the legislatures do not have the
opportunity to update statutes to reflect the new environment. They look
for precedents, as well as the intent of standards bodies to define
industry practice.  Much of the court rulings on Electronic Commerce on the
Internet comes from statutes and rulings applied to Telex and even
telegraph transmissions.

I've been privately consulting several legal experts in this field who
confirm this thesis.

One of them is Mr. Benjamin Wright, author of a widely respected text on
"The Law of Electronic Commerce" which includes the law of email, fax,
digital signatures etc.

I attach a private email which describes the concept...

################################

Date: Wed, 31 Mar 1999 22:23:22 -0500
From: Ben Wright <Ben_Wright at compuserve.com>
Subject: Protecting Internet Fax / Document Transmission
Sender: Ben Wright <Ben_Wright at compuserve.com>
To: Richard Shockey <rshockey at ix.netcom.com>
Message-ID: <199903312224_MC2-702E-490 at compuserve.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by
ixmail9.ix.netcom.com id TAA25128

Message text written by Richard Shockey
>One of the concerns my Work Group has is that sending documents over the
internet could subject recipients to the same kinds of spam and other
attacks we have seen in email. 
We currently have a "junk fax" law that in practice has worked pretty well.
We are wondering is there are things we can do now in documenting our
protocols that would send a signal to the courts [if it becomes necessary]
that we, the designers, are attempting to comply with existing "custom and
practice" re fax transmissions in the hope that protection could be
extended in the future.  Should a test case be brought forward attempting
to enforce the junk fax laws to internet document transmissions .. our
standards documentation could be used as evidence of the "intent of the
designers" etc.<

REPLY:

Thanks for writing me, Richard.  Interesting question.  Generally speaking,
the answer is yes, though it depends.  The designers of protocols could
have an affect on the law by documenting and publicizing what they intended
the protocols to be used for and what the rules of use should be.  Courts
do pay deference to industry custom.  The amount of deference paid depends
on lots of factors, such as how well the designers articulated their ideas,
whether the ideas are logical, how representative the designers were of the
user community, the effort the community exerts to publicize the designer's
intent, and so on.

Cheers

Benjamin Wright
3431-1/2 Granada Ave.
Dallas, TX  75205-2233
Tel: (214) 526-5254
Fax: (214) 526-0026
Ben_Wright at compuserve.com
http://ourworld.compuserve.com/homepages/Ben_Wright


############################################

I really do not want to turn this thread into a Federal Case ( well maybe )
but I continue this argument only to point out that the actions we take now
have uses in the future.

It is not my intent to try and derail v1.1 from advancing to standards
track, far from it. I just hope that the WG can add as much functionality
as possible now.

If it is the rough consensus that time/date responses are not to be
mandated, I can assure you that in future work they will be.

>> 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 continue to submit that fax is simply a form of "remote printing" and the
"facsimile application" is simply a more defined form of general printing.
I see little or no fundamental difference between printing to a IPP device
down the hall .. or printing to a IPP device in Atlanta.


>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...
>

No but add on devices for existing and new machines can incorporate this. I
am assuming that most of this functionality will be available from IPP
installed as a network service in software.  If IPP is run as a network
service..time is clearly available.  I simply do not understand the
objections to this proposal.


>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".

My position is that NOT requiring time/date responses will turn CUSTOMERS
away from IPP.

               
>Finally, any date/time information for faxing comes FROM THE SENDER
>in conventional faxing anyways!  Why should IFAX over IPP be any
>different?

The time/date information in faxing is recorded by both the sender and the
recipient locally. It is not passed on the wire.




>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC                  
8045 Big Bend Blvd. Suite 110    
St. Louis, MO 63119
Voice 314.918.9020
Fax   314.918.9015
INTERNET Mail & IFAX : rshockey at ix.netcom.com
eFAX 815.333.1237  
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



More information about the Ipp mailing list