attachment-0001

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">All,<div><br></div><div>I recently got a CUPS bug report (<a href="http://www.cups.org/str.php?L4072">http://www.cups.org/str.php?L4072</a>) where control characters in the job-name value were causing problems with a particular IPP printer.</div><div><br></div><div>In doing some research on what is allowed for a name value, it seems that RFC 2911 and 3196 don't go beyond referencing the RFCs defining UTF-8 (3629) and US-ASCII (2045), and I don't see anything in those documents that would prevent the use of control characters in the range of 0 to 31 (decimal). &nbsp;Appendix B of RFC 5198 (Unicode Format for Network Interchange) talks a bit about this issue but doesn't make any normative requirements.</div><div><br></div><div>Given the interoperability and security implications of control characters in name and text values, I would like to document the issues and possibly add some normative requirements.&nbsp;Here is what I'd like to add to IPP Everywhere:</div><div><br></div><div>1. Clients and Printers MUST NOT accept or transfer name values containing control characters. For US-ASCII that covers the characters from 0x00 to 0x1F (C0) and for UTF-8/Unicode it covers the characters from 0x00 to 0x1F (C0) and 0x80 to 0x9F (C1).</div><div><br></div><div>2. Clients and Printers MUST NOT accept or transfer text values containing control characters other than CR and LF.</div><div><br></div><div>3. Implementation guidance for Create-Job/Print-Job/Print-URI: Printers MAY filter out disallowed characters in job-name but MUST return job-name in the unsupported attributes group. Status code is client-error-unsupported-attributes-or-values (for ipp-attribute-fidelity=true or job-mandatory-attributes=job-name) or successful-ok-ignored-or-substituted-attributes (otherwise).</div><div><br></div><div>4. Add discussion of security considerations for logging of control characters, specific reference to RFC 5198.</div><div><br></div><div>Thoughts?</div><div><br></div><div><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; border-spacing: 0px; "><div>__________________________________________________</div><div>Michael Sweet, Senior Printing System&nbsp;Engineer, PWG Chair<br></div></span>

</div>
<br></div><br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>