Subject: Re: IPP> clarification needed re: "ipp:" proposal

From: Keith Moore <[email-masked]>
Date: Fri, 03 Jul 1998 21:59:54 -0400

>  however just FYI, I believe either "ipp" or "http" schemes
> MAY be included, but this is dependent upon the means used to determine the
> URL in the first place. The administrator of such a service would publish
> which ever URL was appropriate for how his/her server is configured.

I don't understand.  If you want to advertise a printer, you should use ipp:
If you want to advertise a web server, you should use http:

Seems like the two should have very different user interfaces, which is
one of the reasons for exposing the ipp/http difference in the URL.

For instance, if I click on an http link, I expect my browser or OS
to display that file in a window or offer to save it locally.  

If I click on an ipp link, my browser or OS should pop up
a window offering to print something to that printer, display
the pending jobs in the queue, install a driver for that printer, 
tell me where the printer is and how much it costs to use it, etc.
Or maybe I can drag some other object and drop it on the 
printer link, which causes it to be printed.  etc.
Or I drag the printer link to my desktop, which causes an interface
to that printer to be installed on my system.  Whatever.  The 
point is that just by looking at an ipp: URL, a browser or OS or
a human being can tell that it's a printer, and make use of that
information without actually having to talk to the thing.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 04 Jul 1998 06:55:26 -0400

> On reflection, I should worded my last statement as "clients SHOULD use ipp
> schemes, but MAY use http schemes to contact servers. Servers MUST support
> connections using either http or ipp schemes.

Okay.  If we're talking about URLs that go in HTTP request and response headers,
I'd agree with that.  The big question I have is the URLs that go in IPP
protocol elements.  I think they SHOULD (perhaps MUST) be ipp:.  

More to the point, regardless of what is done on the wire, I think the user 
should always use and see ipp: URLs when referring to a printer.  

Keith
 
> Like I said earlier, I think this will all work, but a detailed I-D will be
> more complete with examples and such.
> 
> On a different tack, I was hoping we could just get away with using
> different methods for IPP, but I was soundly voted down in a past
> conference call. If the  IESG requirement covers more than just being able
> to distinguish IPP traffic from HTTP traffic, then I think a separate
> scheme is the way to go. I'm still re-reading your (Keith) last few
> messages to see if I can extract the exact issue(s) the IESG is concerned
> with. I'm hitting the road tomorrow for our meeting so I hope to have a
> handle on this by Monday.

---

From: Paul Moore <[email-masked]>
Date: Mon, 6 Jul 1998 10:47:39 -0700

This has nothing to do with the IPP protocol - these are suggestions as to
what the users experience should be. There are a million and one web links
that when you click on them do things on the client side. I suspect that a
lot of OS vendors are going to do exactly what you describe. A printer URL
will be HTTP://xxxx/printerA (or whatever). This bears no relationship
whatsoever to the URL used by IPP for pumping print over the network - I
doubt that a user will ever see that URL (in a lot of cases it wont be
http://www.acme.com/myprinter (or IPP: or HTTP:....:370). It will be
something like http://www.acme.com/scripts/IPP/submit.pl?pr=myprinter or
some equally memorable string.

> -----Original Message-----
> From:	Keith Moore [SMTP:[email-masked]]
> Sent:	Friday, July 03, 1998 7:00 PM
> To:	Randy Turner
> Cc:	Keith Moore; Tom Hastings; [email-masked]; [email-masked]
> Subject:	Re: IPP> clarification needed re: "ipp:" proposal 
>