Subject: RE: IPP> Re: IPP Scheme

From: "Bennett, Joel H" <[email-masked]>
Date: Mon, 13 Jul 1998 08:49:53 PDT

>-----Original Message-----
>From: Keith Moore [mailto:[email-masked]]
>
>> MIME type would seem to provide a most adequate filtering hook for IPP
>> and other protocols which also wish to ride on http.  
>
>Filtering is not the issue with ipp: vs. http:.  
>
>The problem with using http: for printers is that it hides the fact 
>that the resource is a printer.  Users then have to keep track of 
>that information separately, while user agents (web clients etc.) 
>are unable to take advantage of the fact that the resource is a 
>printer to improve their user interfaces.

I'm outside your group, strictly speaking, but I was checking this out
because I will be involved in testing the software that XEROX may eventually
develop for IPP.  I couldn't help but weigh in agreeing with Keith on this
one.

Even on existing web pages (never mind on my business cards) users DO see
URL's, and they (we) do make choices based on them.  For instance, when I
point at a link that says "MORE HELP" and the status window of my browser
says mailto:[email-masked] I don't click, because I do NOT want to
waste my time, I'm looking for "more help" not an unresponsive support team.
Likewise, I would want to see ipp://support.microsoft.com so that I would
know that there's no point in clicking unless I've got a complaint/help
document I want to send them!  

Savvy users look for FTP:// instead of HTTP:// when they are trying to
upload/download files, because it's faster and easier than http:// (if only
because ftp:// calls my special ftp client, just the way you will eventually
want ipp:// to load your 
ipp client?)

Web users are used to the idea that http:// is a "viewable" resource.
something they want to LOOK at.  They don't want to do a search for "color
pictures" and get links to http:// sites which are actually printers where
they can "print color pictures."

In HIS hands,
                       Joel H. Bennett
mailto:[email-masked]
http://JBennett.home.ml.org

---

From: Carl Kugler <[email-masked]>
Date: Mon, 13 Jul 1998 13:36:55 -0400

But HTTP/1.1 client MUST use the absolute path form for the Request-URI when
talking to an origin server.  The abs_path part of IPP: and HTTP:  URLs are
identical.

Quote:
"The most common form of Request-URI is that used to identify a resource on an
origin server or gateway. In this case the absolute path of the URI MUST be
transmitted (see section 3.2.1, abs_path) as the Request-URI..."
Or are you discussing HTTP headers other than Request-URI?

  -Carl

[email-masked] on 07/13/98 10:12:36 AM
Please respond to [email-masked]
To: [email-masked], Carl Kugler/Boulder/IBM@ibmus
cc:
Subject: Re: IPP> Re: IPP Scheme

Keith was suggesting that, in the absence of a proxy server, that "ipp:"
URLs would be used in both HTTP headers and in the application/ipp body
part. I believe this would definitely impact generic HTTP 1.1 web servers.

Randy

At 03:53 PM 7/13/98 +0000, Carl Kugler wrote:
>> Some comments on Keith's responses below.
>>
>> Randy
>>
>>
>...
>> >
>> >> 6. Compound schemes is a new idea and not well understood in its'
>> >>    ramifications. In the current IANA registry for URL schemes, there
>> >>    are no examples that indicate that scheme "translation" to another
>> >>    scheme is required.
>> >
>> >IPP is the first group to try to layer something on top of HTTP.
>> >So naturally there are no examples for how to do this.  That's
>> >what comes with breaking new ground.
>> >
>> >Note that the translation is only required to talk to HTTP proxies.
>> >The general case is that the IPP client talks directly to the IPP
>> >server, and there's no URI translation going on at all.
>>
>> Your previous comments that say something like "IPP clients will only use
>> HTTP URLs when speaking to HTTP proxies"  eliminates us from fielding IPP
>> as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These
>> generic
>> web servers will not understand IPP URLs either, and this case of generic
>> web server extension
>> could make up a significant set of initial releases of IPP.
>>
>
>I don't agree that using IPP URLs prevents fielding IPP as CGI or
NSAPI/ISAPI extensions to generic HTTP 1.1 web servers.  Isn't it true that
the web server doesn't need to understand IPP URLs, since they never appear
on the wire (outside of the application/ipp body)?  The one exceptional
case is that in which the client is talking to a proxy server and must
transmit the absolute URL in the Request-URI.
>
>
>-----
>Original Message: http://www.findmail.com/list/ipp/?start=4078
>Start a FREE email list at http://www.FindMail.com/
>

---

From: [email-masked]
Date: Mon, 13 Jul 1998 18:08:06 -0400

>Web users are used to the idea that http:// is a "viewable" resource.

Sorry, there are a large number of non-viewable things that already happen
when I use http:

     - java & javascript
     - management (port 280? 380?)
     - etc.

Perhaps we should have java:, mgmt: URLs?

Either we do it for EVERYTHING or NOTHING; it is too confusing otherwise
and since there are to many pre-existing cases, I don't think we can change
the rules for application/ipp carried on http.

**********************************************
* Don Wright                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: "Bennett, Joel H" <[email-masked]>
Date: Wed, 15 Jul 1998 05:09:57 PDT

So I suppose, if I follow this argument, that the problem with HTTP: is that
it hides the fact that this is really TCP/IP? And perhaps, the problem with
ftp: and mailto: URL's as well?  why to we even need one at all? why not
just have them all be "/www.xerox.com/mypage.html" and
"/printers.xerox.com/myprinter" and "/ftp.xerox.com/myfilestorage"  ;-)

>> >that the resource is a printer.
>>
>> ... and the problem with "ipp:" is that it hides the fact that
>> the protocol is really HTTP!!!
>
>I guess I consider it more important for the URL to describe the
>end resource that it's providing, than for it to describe the
>underlying protocol(s).  We don't have tcp: or ip: URLs; we have
>URLs for higher level services.  Some URL schemes don't imply a
>particular protocol.  However, for every URL scheme that uses the
>name of a protocol, the URL names the highest layer protocol
>on the stack, rather than some lower layer.
>
>Keith

As always, in HIS hands,
                       Joel H. Bennett
mail <mailto:[email-masked]>
web <http://JBennett.home.ml.org>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
QOTD:
All charming people, I fancy, are spoiled. It is the secret of their
attraction.,
-- Oscar Wilde: 1854-1900, Irish writer