IFX Mail Archive: RE: Word docs

RE: Word docs

Michael Crawford (mcrawford@iready.com)
Thu, 25 Mar 1999 12:33:50 -0800

> -----Original Message-----
> From: Richard Shockey [SMTP:rshockey@ix.netcom.com]
> Sent: Thursday, March 25, 1999 11:36 AM
> To: Michael Crawford
> Cc: ifx@pwg.org
> Subject: RE: Word docs
>
> At 11:04 AM 3/25/1999 -0800, you wrote:
> >IPP yes, QUALDOCs maybe not. I think you are right...IPP should be like
> >using a printer on a very long LAN (this doesn't suppose 10baseT by the
> way,
> >PPP dialup should qualify!).
>
> Of course it is assumed that any IPP 1.0/1.1 client could use a dial up
> connection.
*** Hmm. Isn't it difficult to have a "server" application that isn'
there to serve (i.e.
not dialed up when you request service)? Did I miss discussion of
that in the IPP
docs? If I did, I sincerely would like to be pointed to that topic
discussion, I am
truly interested in all things around serving and dialup (for
instance, HTTP server
which is on a dialup connection, and how ISPs manage to support
this...via static
routes seems popular but are there other more intelligent means of
doing this...like
routing protocols that don't mark an interface down permanently over
long downtime
intervals when a dialup connection is not connected).

> >But the original name was IPP2FAX of something along thoselines, and I
> wasn't under the >impression we had moved all that far from thatdirection.
> There was some discussion in >Minnesota about the name, and I went away
> thinking that we were trying to make better >faxing and a smaller
> implementation of IPP to make that
> >possible. If this also helps simplify the remote printing solution,
> great!
>
> Well the goal is the "reliable transmission and reception of documents
> rendered in their
> original form." etc. see below for other issues
>
> We really should not be talking about a "smaller implementation of IPP"
> thats really not the case. IPP is very very flexible in how it can be
> implemented. Carl-Uno Manros the IPP Chair demonstrated at the IETF
> meeting
> a total IPP implementation in print server form (with Ethernet) that was
> no
> larger than a pack of cigarettes. The IPP documentation can be
> intimidating
> to review, at first, but it quickly becomes clear that it is not necessary
> to implement every single feature available.
>
*** I see your point. Why don't we just use IPP then? I thought we
decided
we don't need all of IPP...so isn't the result a subset...i.e.
"smaller" footprint?

By the way I can do what Carl-Uno was holding up in Silicon and less
than a
couple hundred milliwatts (SANS disk and 10MB of memory). We're
talking
about 100 microns on a side.

Mike

> If you do not wish to support certain features.. fine. The exchange of
> supported values and attributes is what is important. The question is what
> values and attributes need to be augmented or their behaivor modified to
> satisify our goals.
>
>