Subject: IPP> Proposal for new IPP scheme

From: "Turner, Randy" <[email-masked]>
Date: Tue, 16 Jun 1998 14:25:14 -0700

Please review the attached summary of Larry's proposal for a new IPP
scheme. I added some clarifications and a particular scenario for scheme
interpretation. This summary is a brief version that was culled from my
notes, and Larry's subsequent comments to me.
The brevity of this summary is maintained due to the possible inclusion
and modification should the WG (or IESG) decide some additional text is
required for IPP-specific "secure" schemes. For this reason, please
treat this proposal as a first draft.

Randy

 <<maspro.txt>>

---

From: Paul Moore <[email-masked]>
Date: Tue, 16 Jun 1998 16:36:50 -0700

We are getting way of course here - we are supposed to be defining a wire
protocol. I would also push back against the pseudo addressing scheme being
proposed since this entirely an artifact within the client (it has no impact
on the protocol itself).

> -----Original Message-----
> From:	Carl-Uno Manros [SMTP:[email-masked]]
> Sent:	Tuesday, June 16, 1998 4:22 PM
> To:	[email-masked]
> Subject:	Re: IPP> Proposal for new IPP scheme
> 
> At 02:25 PM 6/16/98 PDT, Turner, Randy wrote:
> >	
> >Attachment Converted:
> "C:\WINNT\profiles\cmanros\personal\Attach\maspro.txt"
> >
> 
> Randy,
> 
> Did you have any discussion with Larry about what a browser is expected to
> do if your enter an ipp: URL and hit Enter?
> 
> All other URLs that I am aware of do something sensensible in that
> situation. The closest equivalent I can think of is the mailto: URL which
> usually comes up with a mail submission window. Should an ipp: URL come up
> with a print submission window? If so, do we have anybody that might
> commit
> to implement that?
> 
> All in all, I think there is more than meets the eye to introduce a new
> scheme, in particular one that really is an alias for another scheme,
> which
> as far as I know, is a new kind of animal in the IETF garden of Eden.
> 
> Carl-Uno
> 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]

---

From: Robert Herriot <[email-masked]>
Date: Tue, 16 Jun 1998 16:39:59 -0700

This looked like a reasonable proposal until I got to the very last line:

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

The whole proposal is one of keeping ipp as a convenience notation and 
making ipp not appear on the wire. So why should a server ever have to 
accept #3 above?

Bob Herriot

At 02:25 PM 6/16/98 , Turner, Randy wrote:
>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.
>
>For the examples in this proposal the port number 374 is used as the
>port number that might be allocated by IANA. NOTE: this port number
>selection is for illustrative purposes of this text only. 
>
>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 374. 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 374 on myhost.com, with the following example headers:
>
>POST /myprinter/myqueue HTTP/1.1
>Host: myhost.com:374
>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:374/myprinter/myqueue HTTP/1.1
>Host: myproxy.com:374
>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:374/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:374/myprinter/myqueue)
>              3. A full IPP URL   (e.g., ipp://myhost.com/myprinter/myqueue)
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 16 Jun 1998 21:14:59 -0700

Bob,

I do not agree with you on the port number. In every Internet protocol
specification that I have seen there is talk about port numbers.
You could argue that as we are using HTTP, we should use the port number for 
that. BTW, we are talking about DEFAULT port numbers, I hope that is still
clear to everybody (you could still support port 80, but your printer
must be able to use the new IPP port out of the box, at least that is my
understanding). 

Unfortunately you did not make it to our phone conference with the 
Area Directors last week, in which they rather categorically declared that 
the IESG expects new protcols, such as IPP, to use new port numbers and if 
we want to get the IPP specifications past them, we WILL have a new DEFAULT 
port number for IPP. We can keep on arguing this point, but I think we are 
just wasting our time right now.

As for the new scheme, I tend to agree that this really falls outside 
the protocol and does not neccessarily needs to be resolved as part of 
the IPP V1.0. Remains to also convince the Area Directors that this
is the case.

Carl-Uno

At 05:37 PM 6/16/98 -0700, Robert Herriot wrote:
>Actually the default port never hits the wire either.  Both the default port 
>and the ipp scheme-name are smoke and mirrors on the client which give the 
>illusion of an ipp scheme.
>
>On the wire there is nothing but http with default port 80.
>
>If the IPP RFC's should specify wire protocol only, then they should not 
>discuss ipp schemes or default ports. If we believe the IPP RFC's should 
>give some hints for implementing clients, then the proposal from Randy about 
>the ipp scheme and default ports is reasonable except for the last line.
>
>Bob Herriot
>
>At 05:04 PM 6/16/98 , [email-masked] wrote:
>>The more I think about this, the more I think it is out of scope for the
>>work we are doing.  We are working on the wire protocol and encoding for
>>IPP, so ...
>>
>>- Getting a port number allocated for IPP is OK
>>- Specifying that port as the default port is OK
>>- Creating a new scheme that never hits the wire and is handled inside
>>clients and servers is NOT a wire protocol issue.
>>
>>While I think this material could be a interesting proposal and possibly an
>>informational RFC or maybe even more, I don't think it belongs in the
>>standard track RFCs that define IPP.  While I am against a new method, at
>>least it is a wire level issue.
>>
>>... my 2 cents worth ...
>>
>>**********************************************
>>* 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)    *
>>**********************************************
>> 
><html>
><font size=3>Actually the default port never hits the wire either.&nbsp;
>Both the default port <br>
>and the ipp scheme-name are smoke and mirrors on the client which give
>the <br>
>illusion of an ipp scheme.<br>
><br>
>On the wire there is nothing but http with default port 80.<br>
><br>
>If the IPP RFC's should specify wire protocol only, then they should not
><br>
>discuss ipp schemes or default ports. If we believe the IPP RFC's should
><br>
>give some hints for implementing clients, then the proposal from Randy
>about <br>
>the ipp scheme and default ports is reasonable except for the last
>line.<br>
><br>
>Bob Herriot<br>
><br>
>At 05:04 PM 6/16/98 , [email-masked] wrote:<br>
>&gt;The more I think about this, the more I think it is out of scope for
>the<br>
>&gt;work we are doing.&nbsp; We are working on the wire protocol and
>encoding for<br>
>&gt;IPP, so ...<br>
>&gt;<br>
>&gt;- Getting a port number allocated for IPP is OK<br>
>&gt;- Specifying that port as the default port is OK<br>
>&gt;- Creating a new scheme that never hits the wire and is handled
>inside<br>
>&gt;clients and servers is NOT a wire protocol issue.<br>
>&gt;<br>
>&gt;While I think this material could be a interesting proposal and
>possibly an<br>
>&gt;informational RFC or maybe even more, I don't think it belongs in
>the<br>
>&gt;standard track RFCs that define IPP.&nbsp; While I am against a new
>method, at<br>
>&gt;least it is a wire level issue.<br>
>&gt;<br>
>&gt;... my 2 cents worth ...<br>
>&gt;<br>
>&gt;**********************************************<br>
>&gt;* Don
>Wright&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;
>[email-masked] *<br>
>&gt;* Product Manager, Strategic
>Alliances&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *<br>
>&gt;* Lexmark
>International&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>*<br>
>&gt;* 740 New Circle
>Rd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>*<br>
>&gt;* Lexington, Ky
>40550&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>*<br>
>&gt;* 606-232-4808 (phone) 606-232-6740 (fax)&nbsp;&nbsp;&nbsp; *<br>
>&gt;**********************************************<br>
>&gt; </font><br>
></html>
>