IPP Mail Archive: IPP> IPPv2 I18N and Security sections

IPP> IPPv2 I18N and Security sections

From: Ira McDonald (blueroofmusic@gmail.com)
Date: Thu Sep 18 2008 - 21:57:42 EDT

  • Next message: Ron.Bergman@ricoh-usa.com: "IPP> Reminder: IPPv2 Teleconference Monday, September 22 at 4:00PM EDT"

    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@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/




    This archive was generated by hypermail 2.1.4 : Thu Sep 18 2008 - 21:57:56 EDT