Please note that the IPP URL Scheme draft is marked "IPP/NV" for Next
We still have several issues to resolve in order to make the IPP URL Scheme
TLS work, and we decided in the meeting last week that holding up IPP/V1.0
they are all resolved is undesirable.
> -----Original Message-----
> From: Carl Kugler [mailto:kugler at us.ibm.com]
> Sent: Wednesday, November 18, 1998 3:22 PM
> To: ipp at pwg.org> Subject: Re: IPP> IPP Meeting Discussion about IPP URL Sch
>>> 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
>> > For a single Printer object, an administrator configures
> the "printer-uri-supported" and "uri-security-supported"
> attributes as follows:
> '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.
>> > -----
> > See the original message at
See the original message at http://www.egroups.com/list/ipp/?start=4876