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

Randy Turner <rturner@sharplabs.com> Sat, 04 July 1998 03:38 UTC

Delivery-Date: Fri, 03 Jul 1998 23:38:07 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA07544 for <ietf-archive@ietf.org>; Fri, 3 Jul 1998 23:38:06 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA26142 for <ietf-archive@cnri.reston.va.us>; Fri, 3 Jul 1998 23:40:27 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA23290 for <ietf-archive@cnri.reston.va.us>; Fri, 3 Jul 1998 23:38:05 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Fri, 3 Jul 1998 23:32:39 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA22661 for ipp-outgoing; Fri, 3 Jul 1998 23:28:51 -0400 (EDT)
Message-Id: <199807040330.UAA12233@mail.pacifier.com>
X-Sender: rturner@webmail.sharplabs.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 03 Jul 1998 20:25:06 -0700
To: Keith Moore <moore@cs.utk.edu>
From: Randy Turner <rturner@sharplabs.com>
Subject: Re: IPP> clarification needed re: "ipp:" proposal
Cc: ipp@pwg.org
In-Reply-To: <199807040159.VAA21847@spot.cs.utk.edu>
References: <Your message of "Fri, 03 Jul 1998 17:45:23 PDT." <199807040050.RAA27752@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipp@pwg.org

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.

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.


Randy


At 09:59 PM 7/3/98 -0400, Keith Moore wrote:
>>  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
>