I agree we need to be careful of the terminology.
What about the name of the extra URI Printer attribute?
The minutes suggest the name "secure-printer-uri" to go along with
the existing "printer-uri" attribute. Same for the directory schema.
Maybe we should go back to the name that was in the Model document:
"printer-tls-uri"
Here is the suggested text for both the "printer-uri" and the
"printer-tls-uri" attributes.
The current "printer-uri" description is:
4.4.1 printer-uri (uri)
This MANDATORY Printer attribute contains the URI for the Printer object.
An administrator determines a printer's URI and sets this attribute to that
URI. This MUST be an HTTP schemed URI, however the precise format of a
printer URI is implementation dependent.
We need to add text to both about the 'no-value' case as agreed to in
the telecon and described in Roger's minutes:
4.4.1 printer-uri (uri)
This MANDATORY Printer attribute contains the URI for the Printer object.
An administrator determines a printer's URI and sets this attribute to that
URI. This MUST be an HTTP schemed URI, however the precise format of a
printer URI is implementation dependent.
If the administrator configures the Printer to use TLS security only,
the Printer object SHALL return a 'no-value' for this attribute when
queried (on the TLS security port - see Section 4.4.2).
4.4.2 printer-tls-uri (uri)
This MANDATORY Printer attribute contains the TLS URI for the Printer
object. An administrator determines a printer's TLS URI and sets this
attribute to that URI. This MUST be an HTTPS schemed URI, however the
precise format of a TLS printer URI is implementation dependent.
If the administrator configures the Printer to not use TLS security or the
implementation does not support TLS, the Printer object SHALL return
a 'no-value' for this attribute when queried (on the HTTP port - see
Section 4.4.1).
Tom
At 16:58 11/17/1997 PST, Carl-Uno Manros wrote:
>>Randy and other looking at improving our text on security,
>>In our earlier discussions, we have loosely spoken about "secure" and
>"insecure" URIs for IPP etc. I suggest that we need to come up with better
>terms for the actual text in the draft documents, such as:
>> HTTP URI: TLS URI:
>> Basic security Enhanced security
> Simple security Advanced security
>>What I want to avoid is to call the first case "insecure" or "non-secure"
>as it contains the case where RFC 2069 is used, which by many is considered
>to be enough of security for a particular IPP printer.
>>Carl-Uno
>Carl-Uno Manros
>Principal Engineer - Advanced Printing Standards - Xerox Corporation
>701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
>Phone +1-310-333 8273, Fax +1-310-333 5514
>Email: manros at cp10.es.xerox.com>>