Subject: RE: IPP> ipp: / http: in the UI

From: Paul Moore <[email-masked]>
Date: Wed, 15 Jul 1998 11:13:01 -0700

You misunderstand my suggestion. I mean that printto: is like mailto: - it
loads a client and passes in the destination address. It has nothing to do
with the protocol that gets used to send the print. 

> -----Original Message-----
> From:	Jay Martin [SMTP:[email-masked]]
> Sent:	Wednesday, July 15, 1998 10:40 AM
> To:	Paul Moore
> Cc:	[email-masked]'
> Subject:	Re: IPP> ipp: / http: in the UI
> 
> Paul,
> 
> > (Actually I quite like 'printto:' - what do others think).
> 
> Glad you brought this up.  If the final resolution of this whole
> scheme issue results in something *other* than "http:", then
> I'd prefer Keith's suggestion of "print:" as a scheme as opposed
> to your "printto:", since the "to" suffix is both unnecessary
> and counter-intuitive (given that the PDU can very well contain
> requests that are not job submissions).
> 
> 
> > Saying that IPP lets me know that its a printer is an excuse for bad
> design.
> > Any UI  that expects people to differentiate by hovering over the link
> and
> > looking at the status bar is broken.
> 
> Perhaps you're right that the UI should *not* expect this
> "hovering" behavior, but nonetheless it is quite prevalent
> from what I've experienced.  That is, I don't think we should
> discount the frequency and value of hovering as part of a
> positive user experience.
> 
> 
> > Nobody is going to put printer URLs on their business cards.
> 
> Do you really believe this?  I mean, an aweful lot of IPP
> proponents (in the PWG) clearly believe that one of the greatest
> values of IPP is its use as a fax-alike mechanism.  I honestly
> don't think such a capability is nearly as powerful a potential
> as some of these people seem to believe, but there will be some
> who actually implement this, IMHO.
> 
> 	...jay
> 
> ----------------------------------------------------------------------
> --  JK Martin               |  Email:   [email-masked]          --
> --  Underscore, Inc.        |  Voice:   (603) 889-7000              --
> --  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
> --  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
> ----------------------------------------------------------------------

---

From: "Bennett, Joel H" <[email-masked]>
Date: Wed, 15 Jul 1998 11:34:32 PDT

I'm just beginning to get a handle on this, but do most of you envision this
"ipp://printer" or "http://printer:633" or "printo:printer" being handled by
the users web client (ie netscape)?  I had assumed that most companies would
want to develope their own clients, and that in the future users would be
able to choose any company's client they preffered, or even a
free/share-ware solution.

IF you ARE talking about the necesity of developing specialized internet
print clients (as opposed to a java client that loads from a web page or
some-such), then it seems to me that you would want to settle on a scheme
such as "printto:" or "printer:" which would in fact call up a seperate
client.

How are most of you planning on this being implemented?  (do you really want
to trust your printer's interface to the MS/Netscape war?)

Original Message: 
  _____  

	From: Paul Moore [mailto:[email-masked]]

	You misunderstand my suggestion. I mean that printto: is like
mailto: - it
	loads a client and passes in the destination address. It has nothing
to do
	with the protocol that gets used to send the print. 

As always, in HIS hands,
                   Joel H. Bennett
<mailto:[email-masked]> 

<http://jbennett.home.ml.org/>  
  _____  

QOTD: 
Dictatorship (n): a form of government under which everything which is
not prohibited is compulsory. 
  _____

---

From: Harry Lewis <[email-masked]>
Date: Wed, 15 Jul 1998 16:51:38 -0400

It's not necessarily either/or, in my mind. OS support is paramount so good
thing we have Microsoft, Novell, Apple and IBM on the team! They will provide
the infrastructure upon which integrated clients may be developed. Also, there
will be clients which evolve as elements of higher order print and print
management software solutions, I'm sure. But none of this precludes the
possibility of recognition by generic web clients or commonplace web
infrastructure (i.e. Netscape as you put it).

Today, (for example) if I'm checking the weather in Boulder at
http://www.atd.ucar.edu/cgi-bin/flabweatherE  and I want to contact the weather
station manager, placing my cursor over his e-mail link results in the URL
mailto:[email-masked] in my browser command line. When I click, my mail
composition client (of choice) is launched and Mr. Cook's address is
automatically filled out for me. There is no reason why, tomorrow, I couldn't
(hope to) be viewing a white paper on the WEB which has a "printto", "print" or
"ipp" link that behaves in a similar manner whereby clicking invokes the native
IPP client, or client of choice, merrily helping me launch my print job