My understanding is that Keith is trying to dictate that IPP CANNOT USE=
"http" - full stop.
My understand is different, and Larry Masinter expresses my interpretat=
ion very
well (attached). Are Larry and I the only ones who read it this way? Ke=
ith,
please clarify.
Harry Lewis - IBM Printing Systems
owner-ipp@pwg.org on 06/04/98 08:53:15 AM
Please respond to owner-ipp@pwg.org
To: hardie@nic.nasa.gov, joshco@microsoft.com, http-wg@hplb.hpl.hp.com,=
manros@cp10.es.xerox.com, SISAACSON@novell.com, masinter@parc.xerox.com=
cc: ipp@pwg.org, moore@cs.utk.edu
Subject: RE: IPP> Re: Implications of introducing new scheme and port
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 p=
ort.
>>
>> - 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 =3D=3D=3D 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 transla=
tion
>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 raise=
d
in Keith's feedback has to do with firewalls. Also, we are not discussi=
ng
how easy or not it is to change the specs, but what the consequences ar=
e
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
=