Not so. Every IPP packet is a fully conformant HTTP packet. We are not
inventing a new protocol in the scheme sense. Point any lan sniffer at an
IPP exchange and ask it what the protocol is - it will say its HTTP. The
argument you are using would say that SMTP is not TCP/IP. IPP is layered on
top of HTTP - same way that form-based upload is.
-----Original Message-----
From: Keith Moore [mailto:moore at cs.utk.edu]
Sent: Thursday, July 02, 1998 11:16 AM
To: Paul Moore
Cc: 'Keith Moore'; ipp at pwg.org; moore at cs.utk.edu
Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)
> My fundamental objection is that we are being asked to use a new concept
> 'psuedo-schemes' without this idea being drilled into at all. There should
> at least be an I-Draft discussing the idea.
Actually, it's the other way around. IPP is designing a new protocol.
It happens to look a lot like HTTP, and there's no problem with that.
But the notion that IPP can insist that their protocol should use
the same URL type as an existing protocol, is a significant departure
from well-established practice that requires substantial justification.
> Secondly there were many details that needed to be clarified. Was this
> simply a client convenience or did 'ipp:' ever go over the wire being the
> deepest one. The general idea seems to be that it is a user convenience
> thing.
No, ipp: needs to go over the wire in all of the IPP protocol elements.
> In this case it is a client implementation issue and has nothing to
> do with the wire protocol (which is what this discussion is about) and so
> should not be accepted.
It's not just a client implementation issue; it affects servers also.
Nearly every new protocol these days gets a new URL type.
The issues with use of ipp: are no worse than for any other protocol.
Keith