IPP Mail Archive: RE: IPP> Re: Implications of introducing new scheme and

RE: IPP> Re: Implications of introducing new scheme and

Robert Herriot (robert.herriot@Eng.Sun.COM)
Thu, 04 Jun 1998 13:04:24 -0700

--=====================_5345696==_.ALT
Content-Type: text/plain; charset="us-ascii"

Larry,

I am still confused about your suggestion, even after much discussion on the
DL.

When you talk about using an ipp scheme, do you still expect the protocol to
be HTTP with a request line containing something like "POST
/servlet/ippservlet/foo HTTP/1.1"?

If I am correct, then the ipp scheme is not seen by the server (as in my
example above where it has been stripped). Does the client strip the ipp or
does the proxy do it?

It would help if you would state the step by step process for a client to
send an operation using an ipp scheme to an HTTP server.

Bob Herriot

At 10:58 PM 6/3/98 , 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.
>

--=====================_5345696==_.ALT
Content-Type: text/html; charset="us-ascii"

Larry,

I am still confused about your suggestion, even after much discussion on the
DL.

When you talk about using an ipp scheme, do you still expect the protocol to
be HTTP with a request line containing something like "POST 
/servlet/ippservlet/foo  HTTP/1.1"?

If I am correct, then the ipp scheme is not seen by the server (as in my
example above where it has been stripped).  Does the client strip the ipp or
does the proxy do it?

It would help if you would state the step by step process for a client to
send an operation using an ipp scheme to an HTTP server.

Bob Herriot

At 10:58 PM 6/3/98 , 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.
>

--=====================_5345696==_.ALT--