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