Keith was suggesting that, in the absence of a proxy server, that "ipp:"
URLs would be used in both HTTP headers and in the application/ipp body
part. I believe this would definitely impact generic HTTP 1.1 web servers.
Randy
At 03:53 PM 7/13/98 +0000, Carl Kugler wrote:
>> Some comments on Keith's responses below.
>>>> Randy
>>>>>...
>> >
>> >> 6. Compound schemes is a new idea and not well understood in its'
>> >> ramifications. In the current IANA registry for URL schemes, there
>> >> are no examples that indicate that scheme "translation" to another
>> >> scheme is required.
>> >
>> >IPP is the first group to try to layer something on top of HTTP.
>> >So naturally there are no examples for how to do this. That's
>> >what comes with breaking new ground.
>> >
>> >Note that the translation is only required to talk to HTTP proxies.
>> >The general case is that the IPP client talks directly to the IPP
>> >server, and there's no URI translation going on at all.
>>>> Your previous comments that say something like "IPP clients will only use
>> HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP
>> as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These
>> generic
>> web servers will not understand IPP URLs either, and this case of generic
>> web server extension
>> could make up a significant set of initial releases of IPP.
>>>>I don't agree that using IPP URLs prevents fielding IPP as CGI or
NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. Isn't it true that
the web server doesn't need to understand IPP URLs, since they never appear
on the wire (outside of the application/ipp body)? The one exceptional
case is that in which the client is talking to a proxy server and must
transmit the absolute URL in the Request-URI.
>>>-----
>Original Message: http://www.findmail.com/list/ipp/?start=4078>Start a FREE email list at http://www.FindMail.com/>