RE: IPP> Implications of introducing new scheme and port f

To restate, I disagree.
Standardizing a default destination port for IPP doesnt
affect routing through proxy servers.
The proxy listening port doesnt need to change.
Just like when doing 'normal' http, the proxy listening
port has nothing to do with the destination port in the URL.

If you have a URL:
http://mywebserver.domain.com:8000/index.html
or
http://myprinter:5150/queue1/

and a proxy setting of 
http://myproxy:8080/

the proxy's listening port typically is 8080 or 80,
but does not matter.  The client http library knows
via some config setting which port and host to connect
to when speaking the 'http proxy mechanism'.

The only restraint is if your proxy is configured to
restrict URLS to only port 80.
eg proxied URLs of the type:
http://server/index.html 
or
http://server:80/index.html

which due to the popularity of servers running
on ports other than 80 (perhaps for a user non-root server
on a unix machine), is difficult to maintain.

> -----Original Message-----
> From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com
> [mailto:PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com]
> Sent: Monday, June 01, 1998 11:54 AM
> To: manros@cp10.es.xerox.com
> Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org
> Subject: Re: IPP> Implications of introducing new scheme and port f
> 
> 
>      Regarding item #2,
>      
>      Use of alternative HTTP ports, other than port 80, 
> effects the ability 
>      to move through proxies and firewalls. Using alternative 
> port #'s will 
>      require reconfiguration of security infrastructure in 
> order to allow 
>      for HTTP connections. 
>      
>      HP has gone through similar work in the definition and 
> standardization 
>      of HTTP port 280 for Web Based Management Purposes ( see 
> IANA port 
>      list ). Currently port 280 is IANA approved for usage of 
> HTTP for 
>      network management. This works fine for Intranet usage, 
> but issues as 
>      described above result when operating in a secure environments.
>      
>      The other issue is that of configuring HTTP servers and 
> proxies to 
>      listen on alternative port #s. While easy to do 
> programatically, not 
>      all commercial HTTP servers allow listening on multiple ports 
>      concurrently.
>      
>      Considering these two issues, partitioning of the URI 
> space for IPP on 
>      HTTP port 80 or HTTP-S (HTTP/(SSL |TLS)) on port 443 
> makes better 
>      sense.
>      
>      Peter
> 
> 
> ______________________________ Reply Separator 
> _________________________________
> Subject: IPP> Implications of introducing new scheme and port for e
> Author:  Non-HP-manros (manros@cp10.es.xerox.com) at 
> HP-Roseville,mimegw4
> Date:    6/1/98 10:20 AM
> 
> 
> Hi,
>      
> As most of you know already, the Internet Printing Protocol 
> (IPP) WG has 
> suggested using HTTP as "transport", with the payload in the 
> form of a MIME 
> object passed with the POST method.
>      
> As part of the onging IESG review process, the Application 
> Area Director 
> Keith Moore has suggested to distinguish IPP traffic from 
> "normal" HTTP 
> traffic by: 
>      
> 1) the introduction of a new scheme called "ipp"
> 2) the introduction a new default port number for IPP servers.
>      
> Before the IPP WG responds to those suggestions, the IPP WG 
> would like to 
> get some advice from the HTTP WG on the implications of such a change.
> In particular, we want some feedback on how easy or difficult 
> it would be 
> to configure existing web servers to accomodate the suggested changes.
>      
> Please note that many printer vendors are not in the business 
> of developing 
> web servers or HTTP servers and are dependent on getting 
> those compoments 
> from other vendors.
>      
> Please respond back to the IPP DL at:
>      
>         ipp@pwg.org
>      
> Thanks,
>      
> Carl-Uno Manros
> Chair of the IETF IPP WG
>

Received on Monday, 1 June 1998 12:52:07 UTC