Note: this is further discussion of IPP/NV, rather than a problem with IPP/1.0, which I agree will work as is.
Randy-
Where does the URL come from without SLP or LDAP? I'm thinking that the need for privacy (SSL encryption) would originate at the client end, since the client is the one sending the sensitive data over the net. A Printer could advertise (through whatever means) an URL for a normal HTTP port (no SSL) which the client could query with Get-Printer-Attributes to learn the secure URL, which it would then use for submitting Jobs. I'm assuming here that the Printer would have two ports, one secure and one unsecure (possibly with restricted capabilities and/or authentication, if desired), just as SSL web servers typically do today.
If the client can only obtain a naked URL with no other information about a Printer, and the Printer only has one, SSL, port, then I agree the problem is not solvable except through guess-and-retry unless the URL has embedded protocol information like an "https" scheme.
-Carl
> Message http://www.egroups.com/list/ipp/?start=4907>>> Yes the -05 spec defines how the HTTP scheme is interpreted.
>> You could use the "ipp:" scheme using the approach in MOD, but you would be broken
> in environments that do not have SLP or LDAP installed. Because the "ipp" scheme
> does not dictate that SSL/TLS negotiation is enabled, and this is the
> "first" thing that happens on the connection, before the client could open a
> 'non-secure' connection and query the server attributes directly.
>> Randy
>>>>> Carl Kugler wrote:
>> > Which brings us back to why not use an "ipp:" scheme? I don't see why we can't
> > do SSL3 with an "ipp:" scheme using the approach given in MOD.
> >
> > What is the HTTP URL standard? The only relevant statement I can find in
> > draft-ietf-http-v11-spec-rev-05 is this:
> > HTTP communication usually takes place over TCP/IP connections. The default
> > port is TCP 80 [19], but other ports can be used. This does not preclude HTTP
> > from being implemented on top of any other protocol on the Internet, or on
> > other networks. HTTP only presumes a reliable transport; any protocol that
> > provides such guarantees can be used; the mapping of the HTTP/1.1 request and
> > response structures onto the transport data units of the protocol in question
> > is outside the scope of this specification.
> >
> > rturner at sharplabs.com on 11/18/98 04:27:29 PM
> > Please respond to rturner at sharplabs.com> > To: Carl Kugler/Boulder/IBM at ibmus> > cc:
> > Subject: Re: IPP> IPP Meeting Discussion about IPP URL Sch
> >
> > The HTTP URL standard says that SSL3 is not utilized for the transport implied
> > by the URL scheme "HTTP".
> >
> > I never was quite comfortable with the text in the model document overriding a
> > known "proposed"
> > standard.
> >
> > Randy
> >
> > Carl Kugler wrote:
> >
> > > Just to follow up on this.
> > >
> > > The draft-ietf-ipp-ipp-scheme-01.txt says:
> > >
> > > > An IPP/1.0 client MUST use an http-URL for non-secure printers and an
> > https-URL for secure printers.
> > >
> > > I don't understand why. In fact, a counter- example is shown in section
> > 4.4.2, "uri-security-supported", of draft-ietf-ipp-model-11.txt:
> > >
> > > > For a single Printer object, an administrator configures the
> > "printer-uri-supported" and "uri-security-supported" attributes as follows:
> > > "printer-uri-supported": 'http://acme.com/open-use-printer',> > 'http://acme.com/restricted-use-printer', 'http://acme.com/private-printer'> > > "uri-security-supported": 'none', 'none', 'ssl3'
> > > ...
> > > >For the third URI, 'http://acme.com/private-printer', the value 'ssl3' in
> > "uri-security-supported" indicates that SSL3 is being used to secure the
> > channel. The client SHOULD be prepared to use SSL3 framing to negotiate an
> > acceptable ciphersuite to use while communicating with the Printer object. In
> > this case, the name implies the use of a secure communications channel, but the
> > fact is made explicit by the presence of the 'ssl3' value in
> > "uri-security-supported". The client does not need to resort to understanding
> > which security it must use by following naming conventions or by parsing the
> > URI to determine which security mechanisms are implied.
> > >
> > > There must be some rationale I've missed that explains why the approach in
> > MOD is insufficient.
> > >
> > > -Carl
> > >
> > > > -----
> > > > See the original message at http://www.egroups.com/list/ipp/?start=4875> > > >
> > > >
> > >
> > > -----
> > > See the original message at http://www.egroups.com/list/ipp/?start=4876>>>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4907