Subject: RE: RE: IPP> Implications of a new scheme, etc

From: Josh Cohen <[email-masked]>
Date: Fri, 5 Jun 1998 17:20:40 -0700

ahh ok.. see below

> -----Original Message-----
> From: Carl Kugler [mailto:[email-masked]]
> Sent: Friday, June 05, 1998 5:04 PM
> To: [email-masked]
> Subject: Re: RE: IPP> Implications of a new scheme, etc
> 
> 
> > Hi Roger,
> > 
> >  I've got some comments on this. (I dont imagine your surprised :)
> > 
> > For the IPP: (new scheme proposals)
> >  I think putting 'no impact' for proxies is 100% inaccurate.
> > a new IPP scheme will break *every* existing Proxy.  I challenge
> > the wg to find a proxy which will pass this exception, if 
> one exists.
> 
> Josh, I think you've misread the chart.  For the proposal 
> that puts the "ipp:" scheme ON THE WIRE, we listed "Breaks 
> most installed  proxies. At best proxies have to be 
> reconfigured". 
Ok, I would make this stronger.  It breaks all proxies.
It wont be a matter of reconfiguration.  No proxy I know
of today can process this without a software change.
At best, the ipp: scheme will need to mapped to
a scheme that the proxy knows about, which these days
is one of : 
http://
ftp://
gopher://
and maybe wais or mailto:

> The column that says "No impact" for Proxies 
> is for the Larry's proposal 
> (http://www.findmail.com/list/ipp/3754.html) which is 
> actually HTTP on the wire.  (See 
> http://www.findmail.com/list/ipp/3785.html for > more info.)
> 
I dont think larry's proposal meets the requirement that
keith is asking for.  Since the client will just map ipp -> http
on the wire and the proxy or firewall will see it just as HTTP.
This doesnt allow the proxy to differentiate IPP from HTTP
in this case, which was what keith seems to be looking for.

>     -Carl
> 
> > 
> > In the case of the new method, most current proxies will be
> > able to handle it with minimal effort, as you indicated, some will
> > handle it as shipped (MSproxy) and some will need a patch. (squid)
> > If this is a holdup for a new method, I volunteer to submit
> > a patch to the squid group to fix this.
> > 
> > To use a new scheme means that proxies must understand the 
> > IPP protocol inner workings (which means that it has to know
> > that its really just HTTP on the wire).   To use a new
> > method means that IPP is a service on HTTP that is identified
> > by its different method (PRINT).
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Roger K Debry [mailto:[email-masked]]
> > > Sent: Friday, June 05, 1998 1:00 PM
> > > To: [email-masked]
> > > Subject: IPP> Implications of a new scheme, etc
> > > 
> > > 
> > > As suggested on Wednesday's teleconference, Harry Lewis,
> > > Carl Kugler, and I produced the attached table (in .pdf format)
> > > which hopefully summarizes the many views which have been
> > > expressed on this subject over the last couple of weeks. Our
> > > intent is that this would help support our position with 
> Keith Moore.
> > > 
> > > 
> > > 
> > > Roger K deBry
> > > Senior Technical Staff Member
> > > Architecture and Technology
> > > IBM Printing Systems
> > > email: [email-masked]
> > > phone: 1-303-924-4080
> > > 
> > 
> > 
>

---

From: "Larry Masinter" <[email-masked]>
Date: Sat, 6 Jun 1998 09:08:51 PDT

I'm sorry that what seems to be a simple proposal has been so hard
to understand. 

The CLIENT (the thing that actually implements IPP) gets
"ipp://printer.company.com/prt32" as its target. The CLIENT
is wanting to print, so it creates some application/ipp stuff
that indicates the print job, and sends it to
"http://printer.company.com:380/prt32". If it is sending it
through a proxy, the proxy sees "http://printer.company.com:380/prt32".
Since the proxy only sees "http://printer.company.com:380/prt32",
I'm sorry that I've been less than totally clear on this, but it
seems so simple that it wouldn't have to require such a lengthy
explanation.

SCENARIO for client talking to "ipp://printer.company.com/prt32"

Step 1:  Client creates "application/ipp" data.
Step 2:  Client translates "ipp://printer.company.com/prt32"
         to http URL by
         Step 2a: changing scheme from "ipp" to "http"
         Step 2b: adding port 380, if IPP URL doesn't contain a port
         resulting in "http://printer.company.com:380/prt32"

Step 3: Client sends data created in Step 1 to URL created in step 2.
        Step 3a: Request method: the request method is POST
        Step 3b: Request URI:
           if a proxy is in use:
              Step 3b-proxy: the client's HTTP protocol stack
                   will use the entire "http://printer.company.com:380/prt32"
                   URL as the request-URI to the proxy.
          if no proxy is in use:
              Step 3b-noproxy: the client's HTTP protocol
                      stack will use "/prt32" as the request-URI
                      in a connection to "printer.company.com" on port 380
        Step 3c: Host
                The "Host" header should contain "printer.company.com:380"
               corresponding to the HTTP host.
        Step 3d: Content-Type
               The content-type should be application/ipp

Step 4-proxy:
   In the case a proxy is being used, this step occurs at the proxy.
   The proxy receives a request constructed in Step 3, using the
   request URI constructed in Step 3b-proxy. Note that this request
   at the proxy appears as "http://printer.company.com:380/prt32".
   Note that the string "ipp:" does not occur in the request URI.
   Note that the "Host" header constructed in step 3c is matches the
   host in the request-URI.

   Step 4a: the proxy analyzes "http://printer.company.com:380/prt32"
   and notes that it is a HTTP request to "printer.company.com" on port 380.
   
   Step 4b: scheme dispatching
     The proxy dispatches the request to the HTTP request handler,
     since the scheme in the request URI is "http"
   
   Step 4c: domain name filtering and forwarding
     The proxy (potentially) consults its forwarding table to decide
      whether "printer.company.com" on port 380 is an allowed host name
      for forwarding, based on the domain name or a domain name pattern.
      The domain name pattern table may or may not contain port numbers.
      The forwarding table may contain a rewrite rule, e.g., translate
      all requests to "printer.company.com" on port 380 to requests to
      "printer.outsourceagency.com" on port 3724. Such forwarding and
      translation allows services to be redirected without requiring
      renaming or reprogramming.

      The forwarding or filtering rule for a given host or host pattern
      may contain method rules (GET allowed, POST not), which will be
      used subsequently in step 4e below.
 
   Step 4d: IP address filtering & forwarding
     The proxy looks up the domain name in the HTTP request
     "printer.company.com" and gets the IP address for it. The
     proxy (potentially) consults its forwarding table for entries
     based on IP address, in the same manner as domain names were looked
     up in step 4c. As in step 4c, the forwarding or filtering rule
     for a given address or address range may contain method rules
     which will be used in step 4e.

   Step 4e: Method filtering
      The proxy (potentially) examines the method against the allowed
      methods from the lookup in steps 4c or 4d, and decides whether
      the forwarding is allowed.

     Note that generally implementations do not do different forwarding
     based on method ("if you're POSTing, go to this URL instead"), even
     though forwarding based on host or path is common.

   Step 4f: forwarding
     If filtering in steps 4c-4e have not disallowed the request and
     the request is not transformed, a HTTP connection is established to
     "printer.company.com" on port 380, using the request URI "/prt32".

Step 5: Origin server
    The request arrives at the server either directly from the
    client (step 3b-noproxy) or from the proxy (step 4f).
    The server sees a request URI of "/prt32" with a HOST header
    of "printer.company.com:380".

I could elaborate further any of these steps or any subsequent steps if
it's still not clear how this is supposed to work. However, I sincerely
hope I've made it clear how using an "ipp" scheme can work even when
a client is connecting through a proxy, and that this does not "break all
existing proxies" since in no case does the string "ipp" appear at a 
evel that the proxy examines.

Regards,

Larry