At 10:58 PM 6/3/98 PDT, Larry Masinter wrote:
>>>> For example, take a URL that does not explicitly specify a port:
>>>>http://my.domain.com/printer1>>>> - If the client is in the act of printing (browser that is printing
>> or a print only client) the the port to use is the new IPP default port.
>>>> - Any other client will use the HTTP default port
>>This suggestion is completely unworkable. The default port for
>the "http" scheme is 80. It isn't "80 when you use it one way
>and something else when you use it another".
>>I think you can define a new scheme "ipp" and just define it quite
>simply:
>ipp://host/path === http://host:ippport/path (used for ipp)
>>E.g., if the IPP port is "187" then
>ipp://printer.xerox.com/doit>>would be interpreted _exactly_ as
>>http://printer.xerox.com:187/doit>>This equivalence can be done in the client, and need not be handled
>by the proxies at all. Since an ipp client has to know about the rest
>of the ipp protocol anyway, requiring the ipp client to do the translation
>is not a burden.
>>
Larry,
This might be a brilliant idea - if I could only understand what it is that
you suggest. It seems to me that you are suggesting to introduce "ipp", as
a synonym for "http", which you map in both the server and the client?
If that is correct, does that not mean that you are running "http" over
the wire, and hence through the firewall? The whole discussion as raised
in Keith's feedback has to do with firewalls. Also, we are not discussing
how easy or not it is to change the specs, but what the consequences are
for implementors.
My understanding is that Keith is trying to dictate that IPP CANNOT USE
"http" - full stop. Considering that he has been the project advisor, I am
very disappopinted to see that kind of proposal at this stage in the
project.
Carl-Uno