Subject: Re: IPP> Re: New IPP Scheme

From: [email-masked]
Date: Mon, 13 Jul 1998 08:47:37 -0400

My points are:

1.  I am not really concerned about cases where "ipp:" is handled under the
covers by computers.

2.  In cases where people handle URL's, I think the "http:" URL is better
from a number of perspectives which I have already described.  Some how
people seem to figure out business cards that say:

Phone: 606-232-4808
Fax: 606-232-6740

even though the phone numbers look very similar to the fax numbers.
Equally, I think people can handle quite well (largely because it looks
like the familiar web URL they are used to):

Web: http://www.lexmark.com
Printer: http://printer1.bldg035.lexmark.com

**********************************************
* 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)    *
**********************************************

Scott Lawrence <[email-masked]> on 07/13/98
08:20:41 AM

To:   [email-masked]
cc:   Keith Moore <[email-masked]> (bcc: Don
      Wright)
bcc:  Don Wright
Subject:  Re: IPP> Re: New IPP Scheme

[email-masked] wrote:

> >That's not true.  ipp: would appear "on the wire" in all sorts of
> >places -- in HTML documents, LDAP responses, ACAP responses, etc. --
> >any time someone needs to refer to a printer.
> >
> >Keith

[email-masked] wrote:

> Yes, but in all these cases, a human being does not see this raw
material.
> It is technically irrelevant whether the responses say "ipp:", "http:",
or
> anything else for that matter.

Without taking sides on this debate, it is worth pointing out that the
early
developers of the web all thought that ordinary users would never deal
directly with URLs at all - only HTML authors would ever see them.  We all
see them every day in mail, TV, newspapers, billboards...

--
Scott Lawrence            Consulting Engineer        <[email-masked]>
Agranat Systems, Inc.   Embedded Web Technology     http://www.agranat.com/

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Jul 1998 09:14:59 -0400

> people seem to figure out business cards that say:

It's interesting that you should cite that case.  The discussion recently
came up on the URI list as to whether there should be a single "E.164"
URL type for all phone numbers, or whether there should be separate URL
types for voice, fax, etc.

The conclusion was that they had to be separate, because the user 
interfaces for the handling of fax and phone needed to be different, 
and also because in some cases (e.g. ISDN) the call setup actually 
needed to know which was being used before the call was placed.

The http/ipp argument seems very similar to me, with a similar conclusion.

Keith

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 13 Jul 1998 18:37:36 PDT

> Printer: http://printer1.bldg035.lexmark.com
Don, your "printer" URL here is broken and it will fail to work,
because the default port for ipp is "631", so if you are going to
ship a compliant product you will have to write

Web: http://www.lexmark.com
Printer: http://printer1.bldg035.lexmark.com:631

Be sure to get the port right, OK?

If you can't get this little detail right (it's 631, right? Not 632?
Are you sure?) then why do you expect your users to?

Have you had your "user experience" experts test this concept, since
you're making a multi-million-dollar commitment to it?

Regards,

Larry

---

From: Jim Walker <[email-masked]>
Date: Tue, 14 Jul 1998 06:45:00 -0500

Larry Masinter wrote:
> ... yada yada yada ...

But, Larry, you forget that 631 is just a *default* port.  There
is absolutely nothing that says a conforming implementation can't
allow usage on other ports (just as a web server allows usage of
ports other than 80).

So, Don's example is completely legitimate and accurate.  His
administrator (you do have your private sysadmin, don't you
Don ;-) simply chose to configure his IPP printer to run on
port 80.

so there...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 14 Jul 1998 12:40:56 PDT

me:

> compliant product you will have to write
> 

> Don ;-) simply chose to configure his IPP printer to run on

Doesn't this just support the assertion that that using the
"http" would encourage end-users to reconfigure the printers
on their LANs to use the non-standard port 80, merely so
that their users can put "http://printer1.bldg35.lexmark.com" on
their business cards?

Larry

---

From: Robert Herriot <[email-masked]>
Date: Tue, 14 Jul 1998 12:46:29 -0700

If there is going to be a separate "E.164" URL type for voice and fax, how 
does mechanism work for phone numbers that are both voice and fax -- many 
homes have a system that takes voice messages and faxes.  

Bob Herriot

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jul 1998 16:01:50 -0400

> homes have a system that takes voice messages and faxes.  

There is not going to be a separate E.164 URL type.  It was eventually
clear to (nearly) everyone that this was the wrong way to go.

Voice and fax on the same E.164 number are really no different than
multiple services served by the same IP address.  In either case,
we use a different URL scheme name for each service.

Keith

---

From: Robert Herriot <[email-masked]>
Date: Tue, 14 Jul 1998 13:56:36 -0700

If there is one URL scheme for a fax telephone number and another for a voice
telephone number.  What scheme do I use for a telephone number that handles
both fax and voice?  Is there a third scheme that means "voice or fax"?

Bob Herriot

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jul 1998 18:03:36 -0400

> If there is one URL scheme for a fax telephone number and another for a 
> voice telephone number.  What scheme do I use for a telephone number 
> that handles both fax and voice?  

What scheme do you use for an Internet host that handles
smtp+pop+imap+http+ftp?

Keith

---

From: Robert Herriot <[email-masked]>
Date: Wed, 15 Jul 1998 18:41:27 -0700

Action item from Robert Herriot and Tom Hastings:

The IPP working group reached an agreement with Keith Moore in this 
morning's teleconference. This document is our best understanding of the 
details of this agreement.

Summary:

The quick summary is that IPP should support a new scheme 'ipp', which 
clients and servers use in IPP attributes. Such attributes are in a message 
body whose Content-Type is application/ipp.  A client maps 'ipp' URLs to 
'http' URLs, and then follows the HTTP/1.1 rules for constructing a 
Request-Line and HTTP headers. The IPP document will not prohibit 
implementations from supporting other schemes in IPP attributes, but such 
support is not defined by this document.  

Now for the details.

A client and an IPP object (i.e. the server) SHOULD support the 'ipp' scheme 
in the following IPP attributes.  Each of these attributes identifies a 
printer or job object. The 'ipp' scheme is not intended for use in 'uri' 
valued attributes not in this list.

     job attributes - 
        job-uri 
        job-printer-uri
    printer attributes - 
        printer-uri-supported
    operation attributes - 
        job-uri 
        printer-uri

If the scheme of the target URL in a request (i.e. the value of  
"printer-uri" or "job-uri" operation attribute) is some scheme 'x', other 
than 'ipp', the behavior of the IPP object is not defined by this document.  
However, it is RECOMMENDED that if an operation on an IPP object creates a 
new value for any of the above attributes, that attribute has the same 
scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the 
seven attributes above in the response, that the IPP object returns those 
URL values as is, regardless of the scheme of the target URL.

If the client obtains a target URL from a directory service, the scheme of 
the target URL SHOULD be 'ipp'.  If the scheme is not 'ipp', the behavior of 
the client is not defined by this document, but it is RECOMMENDED that the 
client use the URL as is as the target URL.

Although user interfaces are beyond the scope of this document, it is 
RECOMMENDED that if software exposes the URL values of any of the above 
seven attributes to a human user, that the human see the URL as is.  

When a client sends a request, it MUST convert an 'ipp' target URL to an 
'http' target URL for use in the HTTP Request-Line and HTTP headers as 
specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the 
value of the "printer-uri" or "job-uri" attribute in the message body.  If 
the scheme of the target URL is not 'ipp', the behavior of the client is not 
defined by this document, but it is RECOMMENDED that the client use the 
target URL as is in the Request-Line and HTTP headers.
 
A client converts an 'ipp' URL to an 'http' URL by 
    1) replacing the 'ipp' scheme by 'http' 
    2) adding an explicit port 631 if the URL does not contain an explicit 
port.

When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL 
such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection 
to some port (this example uses the IPP default port 631) on some host 
(“myhost.com” in this example) with the following headers:

POST /myprinter/myqueue HTTP/1.1 
Host: myhost.com:631 
Content-type: application/ipp 
Transfer-Encoding: chunked 
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"   
(encoded in application/ipp message body) 
...

When an IPP client sends a request via a proxy, such as “myproxy.com”, to an 
‘ipp’  URL, such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP 
connection to some port (8080 in this example) on some proxy (“myproxy.com” 
in this example) with the following headers:

POST http://myhost.com:631/myprinter/myqueue   HTTP/1.1 
Host: myproxy.com:8080 
Content-type: application/ipp 
Transfer-Encoding: chunked 
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"   
(encoded in application/ipp message body) 
...

The proxy then connects to the IPP origin server with headers that are the 
same as the "no-proxy" example above.

---

From: Randy Turner <[email-masked]>
Date: Wed, 15 Jul 1998 21:38:06 -0700

I read the action items below and it appears very close to our previous usage
model. Except below, this
version says the IPP server "SHOULD" accept "ipp:" URLs wherein I would think
this would be a "MUST",
since later on it mentions that this document does not discuss what a server
does with any other URL 
scheme it sees.

(?)

Randy

At 06:41 PM 7/15/98 -0700, Robert Herriot wrote: 
> POST
> <http://myhost.com:631/myprinter/myqueue>http://myhost.com:631/myprinter/m
> yqueue   HTTP/1.1 
> Host: myproxy.com:8080