Subject: IPP> regarding "ipp:" (I spoke too soon...)

From: Keith Moore <[email-masked]>
Date: Thu, 02 Jul 1998 00:46:24 -0400

On a careful re-reading the list of resolutions for the IPP 
documents, I was surprised to see that the WG had decided not 
to adopt an "ipp:" URL prefix.  (I was out of town last
week and unable to follow the list as closely as I would
have liked.)

In my earlier poll of IESG there was strong agreement that both
a separate port and a new URL prefix were needed, though the
questions were not asked separately  We're having a phone 
conference on July 2 (today or tomorrow depending on your
current time zone), so I'll ask them again just to be sure.

Other than the issue with interoperability with http proxies 
(which are easily addressed), I'd like to know what the
technical problems were with using an "ipp:" prefix.  I've
reviewed most of the list discussion since the teleconference
that I participated in, and didn't see any good explanation
of why this would cause problems.

Keith

---

From: Tom Hastings <[email-masked]>
Date: Fri, 3 Jul 1998 13:26:17 PDT

Keith,

Here is the techical proposal to use a new IPP scheme that we discussed
on the telecon.  It does include the IPP scheme being on the wire in HTTP
headers 
and in IPP requests and responses within the IPP MIME type.  But it also
allows
the HTTP scheme in HTTP headers and in both directions in IPP requests and
responses
within the IPP MIME type.

As stated in the proposal in order to work with existing proxies, the
client would have to change the scheme from ipp to http.  We assumed that
that was ok, since the client would also introduce the default port number,
631,
into the URL, so that the outbound gateway system administrator could restrict
or allow traffic on port 631.  See the example below.  Same for clients
working
through existing HTTP-only libraries.

Do you or the IESG have any technical problems with this complete proposal?
It is a correct description of how a new IPP scheme would work with
clients, proxies, and servers?

There is no point in discussing problems with the new IPP scheme, if we don't
all agree as to what a new IPP scheme really is.

Thanks,
Tom 

****************************************************************************
****
                       Proposal for an IPP scheme

This is the same proposal that Randy and Larry produced on June 16, 1998
and send to the IPP mailing list.  I have only changed the port number 
from 374 to the one assigned to IPP as the IPP default port by IANA on 
June 22, namely, 631.  - TNH 

This is a proposal for the registration of a new URL scheme "ipp".
The syntax for the new IPP scheme would be identical to the existing
"http" scheme except for the scheme name itself:

ipp://host[:port]/<IPP-specific-abs-path>

Associated with this new IPP scheme would be an IANA-assigned TCP port
number, which would be the default port number used by clients to
contact IPP servers that are represented by IPP URLs.

The IPP scheme implies all of the same protocol semantics as that of
the HTTP scheme, except that, by default, the port number used by clients
to connect to the server is port 631. The semantics for clients 
configured for proxy access is different as described below.

When an IPP client obtains an IPP URL, the interpretation of this URL by
the client can take one of three forms, depending on the configuration
and implementation of the client:

------------------------------------------------------
IPP Client Configured with no proxy server -
------------------------------------------------------

When an IPP client (no proxy configured) obtains an IPP-schemed URL such 
as "ipp://myhost.com/myprinter/myqueue, it will open an TCP connection to 
port 631 on myhost.com, with the following example headers:

POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...

------------------------------------------------------
IPP Client Configured for Proxy Service -
------------------------------------------------------

When an IPP client that uses a proxy named "myproxy.com" obtains the URL 
"ipp://myhost.com/myprinter/myqueue", it will open a TCP connection to
myproxy.com with the following example headers:

POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myproxy.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...

It is likely that existing proxies will not understand IPP URLs,
so the RequestURI should use the HTTP form of the URL.

-------------------------------------------------------
IPP Clients with HTTP-only constraints
-------------------------------------------------------
If a particular IPP client implementation uses a pre-packaged HTTP library 
or HTTP class that only supports HTTP-schemed URLs, then the following
operation would be required:

- The IPP client obtains the IPP-schemed URL and converts it to the 
  following form:
                  "http://myhost.com:631/myprinter/myqueue"

The client then submits this URL to the pre-packaged HTTP library API.

-------------------------------------------------------

Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers
using 
a requestURI specified in #1 below. However, RFC 2068 states that HTTP 1.1
servers
should accept "full" URLs as well, so IPP servers should also be able to 
accept requestURIs as specified in #2 and #3 as well.

              1. A "abs_path" URL (e.g., /myprinter/myqueue)
              2. A full HTTP URL  (e.g.,
http://myhost.com:631/myprinter/myqueue)
              3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)

End of Proposal for a new IPP scheme
****************************************************************************
*******

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Jul 1998 17:13:57 -0400

Tom,

The best thing to do at this point would be for me to run this proposal
by the entire IESG when it is balloted.  So I'll include it in the 
formal ballot that gets sent to IESG.

Keith

---

From: Tom Hastings <[email-masked]>
Date: Fri, 3 Jul 1998 14:42:11 PDT

Keith,

How long does an IESG ballot take?  When would it be done?

Isn't there some IESG expert that can bless this proposal now, so that we can
discuss it and put it in our documents?

I'm afraid that the WG is running out of patience with this prolonged
process and I'm trying to see how we can work out a technical solution.
Can't you forward the ipp scheme proposal to some experts for review
now to see if it is acceptable and correct?

Thanks,
Tom

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Jul 1998 19:18:33 -0400

> How long does an IESG ballot take?  When would it be done?

IESG normally meets every other Thursday.  Our last meeting was yesterday.
IPP should be formally discussed by IESG in either two or four weeks' time.
(Normally it would just be two weeks, but these are long documents.)

Up until this point, IESG has been waiting until I could recommend  
the documents to it; and until recently I was waiting for the revisions
in response to my suggestions for changes.  (IESG won't ballot the 
document unless/until the AD in charge of the working group recommends 
that it do so.)

> now to see if it is acceptable and correct?

With all due respect, there's a shortage of patience on both sides,
and the "other side" includes a number of IESG and IAB folks.

*I'm* the expert.  The rest of IESG would prefer to avoid reading the
IPP documents; they'd far rather trust my judgement and vote "No Objection"
But a strong objection from any IESG member can cause the process to
take a lot longer.  But my opinion is irrelevant, as is the opinion of 
other experts, if there's strong objection from other IESG members 
who have read the documents.

I personally think the overall proposal to use ipp: is sound and 
reasonably detailed, but the solution to allow both ipp: and http: 
in IPP protocol elements is marginal.  I'd like the proposal better 
if it said "clients and servers SHOULD use ipp: URLs in IPP protocol 
elements". 

The proposal would be stronger if it provided some justification for 
using http: in IPP protocol elements at all.  It should also 
explain why using http: when talking to proxies isn't an attempt 
to subvert a site's firewall security policy.  It probably needs
to describe a common case where talking directly to the server's
IPP port doesn't work, and the reason it doesn't work is something
other than "access to the IPP port is turned off at the firewall".

My opinion is irrelevant, as is the opinion of other experts, 
if there's strong objection from other IESG members to any use 
of http: in IPP protocol elements. 

It's not like this is the only problem with the documents.  If past 
history is any guide, it's going to be an tough sell for me to 
talk the rest of IESG into letting IPP get away with "SHOULD implement" 
TLS, but I agreed that I would make that pitch.  And I seem to recall 
(I don't have the document in front of me) that IPP refused to add 
the security considerations text regarding downloadable drivers - 
I'm not the only one on IESG who cares about such things.  And 
it's always possible that IESG folks will find other things to object to.

But at this point I think it's to the point that I can should it to
IESG, let them comment on it and recommend changes, and have the 
IPP editors do at most one more pass.   Assuming, of course, that
IPP is willing to make the changes that IESG requests.

The IPP group's work (at least on these documents) is 99% done.  It 
mostly remains for me to sell the work to the IESG.  But because this 
group has generated a fair amount of unfavorable attention from day one, 
it wouldn't surprise me if a number of IESG members paid particular 
attention to it.  

So the group should expect that there will be one more round of 
changes requested.  Most of the changes that IESG requests are 
minor and they're usually editorial in nature.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Jul 1998 19:51:26 -0400

On re-reading the proposal again, I realize that I might have misunderstood 
it.  The proposal doesn't seem to say whether http: URLs are allowed in IPP
protocol elements (as opposed to HTTP request headers when talking to
a proxy.)  On earlier readings I thought it had said that http: would be
allowed.

So it would help to have the proposal explicitly state whether ipp:
URLs (SHOULD|MUST) be used in IPP protocol elements when referring to 
printer or job objects, and whether http: URLs (MAY|SHOULD NOT|MUST NOT)
be used.  And if http: URLs are going to be allowed at this level, 
please explain why they are needed or useful.

thanks,

Keith

---

From: Randy Turner <[email-masked]>
Date: Fri, 03 Jul 1998 17:45:23 -0700

What Larry and I worked on was a quick brief of what we thought were the
major elements of the proposal. It was not an I-D. If sufficient interest
exists in pursuing the proposal (by the WG, IESG, or anyone else), then we
will definitely translate the brief into a draft. The I-D would outline the
exact details, 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.

Randy

---

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

>  however just FYI, I believe either "ipp" or "http" schemes

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: Randy Turner <[email-masked]>
Date: Fri, 03 Jul 1998 20:25:06 -0700

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

---

From: Tom Hastings <[email-masked]>
Date: Sat, 4 Jul 1998 01:59:24 PDT

At 16:18 07/03/98 PDT, Keith Moore wrote:
snip...

>> discuss it and put it in our documents?

snip...

>who have read the documents.

Good!  Then its very important that you review the detailed proposal
that the IPP has been considering to satify your requirements for a
new IPP scheme (but has so far rejected).  It sounds like you like parts
of it, but have some concerns too.  I would think that the proper steps
BEFORE taking IPP to the IESG would be:

1) you finish giving us your feed back on our detailed proposal to
use an IPP scheme (that Randy Turner and Larry Masinter wrote up), 
including conformance wording, etc.

2) we update that proposal and make sure you agree with it.

3) then the IPP WG reviews whether they support the proposal or not
and writes down the problems that they have for your review.

We have an IPP meeting this Wednesday/Thursday, July 8/9, in Monterey.  
It would be nice if we could finish steps 1-3 by the end of that meeting.

Can you participate with us if we setup a phone conference?

Question:  should this usage of the IPP scheme be a separate document
or part of the "Encoding and Transport" (was called Protocol) document?

Thanks,
Tom

>other than "access to the IPP port is turned off at the firewall".

snip...

>IPP is willing to make the changes that IESG requests.

snip...

---

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

> 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

---

From: Tom Hastings <[email-masked]>
Date: Mon, 6 Jul 1998 12:09:48 PDT

>formal ballot that gets sent to IESG.

Keith has said that he wants to forward our proposal (that Randy and Larry
sent to
the IPP mailing list on 6/16) for a new IPP scheme to the IESG along with
our documents.  Until the following shortcomings with the current proposal
for a new IPP scheme are fixed, we are not all talking about the same thing:

1. There are no MUST verbs.

2. There are 3 SHOULD verbs.

3. There are no MAY or NEED NOT verbs.

4. Only the outbound gateway is considered, not the inbound gateway.
(Isn't Keith Moore worried about filtering by an inbound gateway?).

5. There is no statements MUST or SHOULD or MAY or NEED NOT about the
scheme in the URI attributes in the application/ipp MIME type itself, i.e,
in "printer-uri", "job-uri", "printer-uri-supported", etc..

I suggest that we try to improve our proposal in the above areas, working
with Keith, before sending it to the IESG.  If we agree on something at our
Wednesday, IPP meeting, July 8, is there any chance of interacting with
Keith on it at our meeting on Thursday, July 9, by phone?

This is the same proposal that Randy and Larry produced on June 16, 1998
and send to the IPP mailing list.  I have only changed the port number from
374 to the one assigned to IPP as the IPP default port by IANA on June 22,
namely, 631.  I also capitalized the "shoulds" to make them stand out.  - TNH

It is likely that existing proxies will not understand IPP URLs,
so the RequestURI SHOULD use the HTTP form of the URL.

Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers
using a requestURI specified in #1 below. However, RFC 2068 states that
HTTP 1.1
servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be
able to 
accept requestURIs as specified in #2 and #3 as well.

      1. A "abs_path" URL (e.g., /myprinter/myqueue)
      2. A full HTTP URL  (e.g., http://myhost.com:631/myprinter/myqueue)
      3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Jul 1998 19:26:33 -0400

> configured for proxy access is different as described below.

change this to:

The IPP scheme implies use of the Internet Printing Protocol, which
is layered on top of the Hypertext Transfer Protocol (HTTP).  By 
default, IPP clients connect to IPP servers using TCP port 631. 

> and implementation of the client:

change the above line to:

Host: myhost.com

"631" should probably not appear, since it's the default port.

However servers should accept the port # if it does appear.

> Transfer-Encoding: chunked

This section needs justification - why should an IPP client talk to an
HTTP proxy rather than talking directly to the IPP server, unless
the reason is to circumvent the local site's filtering of outbound
traffic on port 631?   (There may well be a good reason, but offhand I
can't think of one.)

(FWIW, This is an implementation issue.  As long as the protocol on the wire 
is the same, IETF doesn't care what you have to do to talk to an API.)

>       3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)

Servers MUST treat all of above forms as equivalent.

Servers MAY provide different services at different domains using 
either full URLs (those that include the domain), or the Host header 
(if one is supplied by the client) to distinguish one domain from another.  
Servers that look at the Host: request header field MUST treat
"Host: foo.com" and "Host: foo.com:631" as equivalent.

Finally:

The use of http: URLs within IPP is only to allow reuse of HTTP libraries,
(or HTTP proxies).   Within IPP protocol elements, ipp: URLs MUST always
be used for URLs that refer to IPP objects.

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 6 Jul 1998 17:56:05 PDT

Keith,

Thanks for your constructive proposal on how to improve the proposal.
This shows more in detail what you believe is the right solution.
I expect that we will discuss this in the upcoming IPP meeting, and be able
to give you feedback later in the week on how the experts in that meeting
view your proposed changes.

Carl-Uno

>be used for URLs that refer to IPP objects.
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]