Hi,
Please see proposed text for IPPv2 Internationalization and Security
sections below and attached.
Cheers,
- Ira
--
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
--------------------------------------------------------
8. Internationalization Considerations
For interoperability and basic support for multiple languages, IPP/1.1
conforming Printer implementations MUST support the UTF-8 [RFC3629]
encoding of Unicode [UNICODE] [ISO10646].
For interoperability and best practice support for multiple languages,
IPP/2.0 conforming Printer implementations SHOULD support Network
Unicode [RFC5198] - which REQUIRES transmission of well-formed UTF-8
strings and RECOMMENDS transmission of normalized UTF-8 strings in
Normalization Form C (NFC) [UAX15].
NFC is defined as the result of performing Canonical Decomposition (into
base characters and combining marks) followed by Canonical Composition
(into canonical composed characters wherever Unicode has assigned them).
NOTE WELL - Performing normalization on UTF-8 strings received from IPP
clients and subsequently storing the results (e.g., in IPP Job objects)
could cause false negatives in IPP client searches and failed access
(e.g., to IPP Printers with percent-encoded UTF-8 URIs now 'hidden').
9. Security Considerations
For interoperability and basic support for security, IPP/1.1 conforming
Printer implementations SHOULD support TLS/1.0 [RFC2246] with a
mandatory cipher suite of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
For interoperability and better support for security, IPP/2.0 conforming
Printer implementations SHOULD support TLS/1.1 [RFC4346] with a
mandatory cipher suite of TLS_RSA_WITH_3DES_EDE_CBC_SHA.
For interoperability and best practice for security, IPP/2.0 conforming
Printer implementations SHOULD support TLS/1.2 [RFC5246] with a
mandatory cipher suite of TLS_RSA_WITH_AES_128_CBC_SHA.
For interoperability and best practice for security, IPP/2.2 conforming
Printer implementations MUST support TLS/1.2 [RFC5246] with a mandatory
cipher suite of TLS_RSA_WITH_AES_128_CBC_SHA.
10.1 Normative References
[ISO10646] "Information Technology - Universal Multiple-octet Coded
Character Set (UCS)", ISO/IEC Standard 10646, 2006.
[RFC2246] T.Dierks, C. Allen, "Transport Layer Security 1.0", RFC 2246,
January 1999, http://www.ietf.org/rfc/rfc2246.txt
[RFC3629] F. Yergeau, "UTF-8 Transformation of ISO 10646", RFC 3629,
November 2003, http://www.ietf.org/rfc/rfc3629.txt
[RFC4346] T.Dierks, E. Rescorla, "Transport Layer Security 1.1",
RFC 4346, April 2006, http://www.ietf.org/rfc/rfc4346.txt
[RFC5246] T.Dierks, E. Rescorla, "Transport Layer Security 1.2",
RFC 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt
[UAX15] M. Davis, M. Duerst, "Unicode Normalization Forms", Unicode
Standard Annex 15, March 2008, http://www.unicode.org/reports/tr15/
[UNICODE] M. Davis, et al, "Unicode Standard v5.1.0", Unicode Standard,
April 2008, http://www.unicode.org/versions/Unicode5.1.0/
-------------- next part --------------
8. Internationalization Considerations
For interoperability and basic support for multiple languages, IPP/1.1
conforming Printer implementations MUST support the UTF-8 [RFC3629]
encoding of Unicode [UNICODE] [ISO10646].
For interoperability and best practice support for multiple languages,
IPP/2.0 conforming Printer implementations SHOULD support Network
Unicode [RFC5198] - which REQUIRES transmission of well-formed UTF-8
strings and RECOMMENDS transmission of normalized UTF-8 strings in
Normalization Form C (NFC) [UAX15].
NFC is defined as the result of performing Canonical Decomposition (into
base characters and combining marks) followed by Canonical Composition
(into canonical composed characters wherever Unicode has assigned them).
NOTE WELL - Performing normalization on UTF-8 strings received from IPP
clients and subsequently storing the results (e.g., in IPP Job objects)
could cause false negatives in IPP client searches and failed access
(e.g., to IPP Printers with percent-encoded UTF-8 URIs now 'hidden').
9. Security Considerations
For interoperability and basic support for security, IPP/1.1 conforming
Printer implementations SHOULD support TLS/1.0 [RFC2246] with a
mandatory cipher suite of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
For interoperability and better support for security, IPP/2.0 conforming
Printer implementations SHOULD support TLS/1.1 [RFC4346] with a
mandatory cipher suite of TLS_RSA_WITH_3DES_EDE_CBC_SHA.
For interoperability and best practice for security, IPP/2.0 conforming
Printer implementations SHOULD support TLS/1.2 [RFC5246] with a
mandatory cipher suite of TLS_RSA_WITH_AES_128_CBC_SHA.
For interoperability and best practice for security, IPP/2.2 conforming
Printer implementations MUST support TLS/1.2 [RFC5246] with a mandatory
cipher suite of TLS_RSA_WITH_AES_128_CBC_SHA.
10.1 Normative References
[ISO10646] "Information Technology - Universal Multiple-octet Coded
Character Set (UCS)", ISO/IEC Standard 10646, 2006.
[RFC2246] T.Dierks, C. Allen, "Transport Layer Security 1.0", RFC 2246,
January 1999, http://www.ietf.org/rfc/rfc2246.txt
[RFC3629] F. Yergeau, "UTF-8 Transformation of ISO 10646", RFC 3629,
November 2003, http://www.ietf.org/rfc/rfc3629.txt
[RFC4346] T.Dierks, E. Rescorla, "Transport Layer Security 1.1",
RFC 4346, April 2006, http://www.ietf.org/rfc/rfc4346.txt
[RFC5246] T.Dierks, E. Rescorla, "Transport Layer Security 1.2",
RFC 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt
[UAX15] M. Davis, M. Duerst, "Unicode Normalization Forms", Unicode
Standard Annex 15, March 2008, http://www.unicode.org/reports/tr15/
[UNICODE] M. Davis, et al, "Unicode Standard v5.1.0", Unicode Standard,
April 2008, http://www.unicode.org/versions/Unicode5.1.0/